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Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The present document is part 2 of a multi-part deliverable covering Broadcast and On-line Services: Search, select and 
rightful use of content on personal storage systems ("TV- Any time"), as identified below: 

Parti: "Benchmark Features"; 

Part 2: "System description"; 

Pai-t 3: "Metadata"; 

Part 4: "Content referencing" ; 

Part 5: "Rights Management and Protection (RMP)"; 

Part 6: "Delivery of metadata over a bi-directional network"; 

Part 7: "Bi-directional metadata delivery protection"; 

Part 8: "Phase 2 - Interchange Data Format"; 

Part 9: "Phase 2 - Remote Programming". 
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Introduction 



"TV-Anytime" (TV A) is a synchronized set of specifications established by the TV-Anytime Forum. TVA features enable 
the search, selection, acquisition and rightful use of content on local and/or remote personal storage systems from both 
broadcast and online services. 

TS 102 822-1 [1] and the present document set the context and system architecture in which the standards for Metadata, 
Content referencing. Bi-directional metadata and Metadata protection are to be implemented in the TV-Anytime 
environment. TS 102 822-1 [1] provides benchmark business models against which the TV-Anytime system architecture 
is evaluated to ensure that the specification enable key business applications. The present document presents the 
TV-Anytime system architecture. These two documents are placed ahead of the others for their obvious introductory 
value. Note that these first two documents are largely informative, while the remainder of the series is normative. 

The features are supported and enabled by the specifications for Metadata (TS 102 822-3 sub-parts 1 [2], 2 [3], 3 [4] 
and 4 [5]), Content Referencing (TS 102 822-4 [6]), Rights Management (TS 102 822-5 sub-parts 1 [7] and 2 [8]), 
Bi-directional Metadata Delivery (TS 102 822-6 sub-parts 1 [9], 2 [10] and 3 [11]) and Protection (TS 102 822-7 [12]), 
Interchange Data Format (TS 102 822-8 [13]) and Remote Programming (TS 102 822-9 [14]). This list of Features is to 
be used as guidance to manufacturers, service providers and content providers regarding the implementation of the 
Phase 1 and Phase 2 TV-Anytime specifications. 

The present document is mainly informative and has therefore not the intention to mandate certain system 
implementation solutions. Preferred solutions, from a technology stand point, will be indicated to allow implementers to 
build more efficient systems. 

Only annex B to this document is normative and contains requirements for delivery systems being designed by users 
of the TV-Anytime specification for their specific operational environment. 
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Scope 



The present document shows the system behaviour of a TV-Anytime broadcast system with an interaction channel used 
for consumer response. The present document contains examples of how to use the TV-Anytime specifications both 
from static and dynamic viewpoints, i.e. it will highlight the parties involved in the processes and show the interaction 
between them. 

The present document is a cookbook or white paper to the TS 102 822-3 sub-parts 1 [2], 2 [3], 3 [4] and 4 [5], 
TS 102 822-4 [6], TS 102 822-5 sub parts 1 [7] and 2 [8], TS 102 822-6 sub-parts 1 [9], 2 [10], and 3 [11], 
TS 102 822-7 [12], TS 102 822-8 [13] and TS 102 822-9 [14]. 

The present document is mainly informative and has therefore not the intention to mandate certain system 
implementation solutions. Preferred solutions, from a technology stand point, will be indicated to allow implementers to 
build more efficient systems. 

Annex B to this document is normative and contains requirements for dehvery systems being designed by users of the 
TV-Anytime specification for their specific operational environment. 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 

acquisition: retrieval of content 

advertising: content that is intended to promote or drive sales for products or services 

application: specific set of functions running on the PDR. Some applications use metadata, either automatically or 
under consumer control 



ETSI 



1 ETSI TS 1 02 822-2 V1 .3.1 (2006-01 ) 

attractor: metadata element that is accessible by the consumer in order to aid in the content selection process, thus 
attracting the consumer 

NOTE: Examples include the title and name of an actor in a television programme. 

avail: term used in the United States to describe an individual interstitial item within for example a commercial break 
also commonly known as a "Spot" 

NOTE: In the UK an avail is used to refer to an interstitial break. 

banner ad: traditionally used to describe images used as advertising on the world wide web 

NOTE: An advertisement comprising a graphic (static or animating) and possible associated audio that is placed 
in association with editorial content. 

bi-directional: system that allows a two-way flow of content and/or information 

capture: storing the acquired content (to local storage) 

consumer profile: data that represents the interests and preferences of the consumer 

content: anything the viewer would like to consume (e.g. movies, games, TV programmes, radio programmes etc.) 

content creator: producers of the content 

content item: entity that can be acquired as a single unit e.g. AV file. Audio stream 

content package: collection of Content Items, which may be consumed as a whole or individually 

content provider: entity that acts as the agent for and is the prime exploiter of the content 

content reference: pointer to a specific content item 

control flow: system related data e.g. consumer queries, transactional information, device capabilities, profile 
information etc. 

data carousel: method for transmitting data over a broadcast channel in which data is cyclically transmitted 

descriptor: metadata element, such as an attractor or other information about content such as the key frame index of a 
piece of video 

enhanced TV: television that includes additional information and/or applications related to content, but does not use a 
return path 

flash: popular authoring software ubiquitous on the Web used to create vector graphics-based animation programs with 
full-screen navigation interfaces, graphic illustrations, and simple interactivity in an antialiased, resizable file format 

free to air: broadcast content that is free at the point of consumption 

NOTE: Free-to-air content can be delivered encrypted or in the clear. 

functional unit: basic logical element, implementing a defined function of a TV-Anytime system 

location resolution: process of establishing the address (location and time) of a specific content instance from its GRID 

interactive TV: television that includes additional information and/or applications related to content and which takes 
advantage of a return path 

interstitial: additional content that may be inserted within, at the start, or at the end of the primary content item 

NOTE: This additional content includes for example advertising spots, station idents, promos and graphics. 

interstitial break: terms used in the United Kingdom to design a group of interstitials shown together 

metadata: generally, data about content, such as the title, genre, summary of a television programme consumer 
preferences and viewing history data 
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metadata schema: identifier associated with a set of XML schemas that globally identifies those schemas so that they 
can be referenced externally 

NOTE: A globally unique namespace ensures that the names of types defined by schemas in that namespace do 
not conflict with types of the same name defined elsewhere. 

metadata system: set of rules describing the syntax and semantics of metadata 

non-skipable: content that is protected in a way that prevents the consumer from avoiding it by using the remote 
control 

pay per view: content for which the consumer had had to pay a one off fee 

pod: set of Avails or Spots that form a commercial break 

programme: editorially coherent piece of content 

NOTE: Typically, a programme is acquired by the PDR as a whole. 
programme group: one or more programmes that are grouped together 

NOTE: TV Anytime defines several types of programme groups such as "series" and "programme compilation". 

return path: part of the bi-directional distribution system from the consumer to service provider 

segmentation: labelling of content that allows it to be broken down into separate discreet elements 

speedbumps: advertising elements ( audio, video or graphics) that are superimposed on screen when a consumer selects 
trick mode on a PDR 

spot: individual content item within an Interstitial break (Pod) 

NOTE: Also commonly referred to as an Avail. TV and Radio industry description for a unit of advertising. 

skipable: content that can be missed by the consumer by using the remote control on a device 

subscription TV: broadcast content that the consumer has paid for through a recurring subscription 

telescope ad: long form advertising spot that is linked to from a shorter spot 

transcode: technical conversion of content from one standard to another 

NOTE: for example converting standard definition broadcast signal to a lower bandwidth web capable standard 
such as Real Media or Windows Media 10. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AAF Advanced Authoring Format 

ACAP Advanced Common Application Platform 

AES Audio Engineering Society 

ARIB Association of Radio Industries and Businesses 

ATSC Advanced Television Systems Committee 

AV Audio-Visual 

AVI Audio-Visual Interface 

CA Conditional Access 

CGMS Copy Generation Management System 

CRID Content Reference IDentifier 

NOTE: An identifier for content that is independent of its location specified by TS 102 822-4 [6]. 

CSP Content Service Provider 

DNS Domain Name System 

DRM Digital Rights Management 
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DS 

DVB 

EPG 



Description Scheme 
Digital Video Broadcasting 
Electronic Programme Guide 



NOTE: A means of presenting available content to the consumer, allowing selection of desired content. 

FTA Free-To-Air 

HD High Definition 

HTTP HyperText Transfer Protocol 

IMI Instance Metadata Identifier 

IP Internet Protocol 

IPR Intellectual Property Rights 

ISAN International Standard Audiovisual Number 

ISO International Organization for Standardization 

MPEG TS MPEG Transport Stream 

MPEG Motion Picture Expert Group 

MXF Metadata eXchange Format 

NDR Network Digital Recorder 

PDA Personal Digital Assistant 

PDC Programme Delivery Control 

PDR Personal Digital Recorder 

PES Packetized Elementary Stream 

PPV Pay-Per-View 

RAR Resolving Authority Record 

RMP Rights Management and Protection 

RMPI Rights Management and Protection Information 

RMPI Rights Management and Protection Information 

RMPI-M Rights Management and Protection Information Micro 

RMPI-MB Rights Management and Protection Information Micro Broadcast 

RSS Really Simple Syndication 

SM local Storage Management 

SMPTE Society of Motion Picture and Television Engineers 

SN Search and Navigation 

SOAP Simple Object Access Protocol 

TVA TV-Anytime 

TVA-RMP TV-Anytime Rights Management and Protection 

UDDI Universal Description Discovery and Integration 

UI User Interaction 

VoD Video on Demand 

WAN Wide Area Networks 



TV-Anytime system architecture 



A simple TV-Anytime broadcast system can be viewed as containing three major elements: a service provider delivering 
the TV-Anytime service, a transport provider that carries the service and a piece of equipment in the home that stores the 
content and plays it back at the consumer's request. This document examines the mechanisms behind this simple model 
and gives a comprehensive functional reference model. This model adapted for the pure broadcast situation is depicted 
in figure 1 . In this figure, a clustering of functions is indicated that is especially relevant in the broadcast case: it shows 
the "PDR" (Personal Digital Recorder). 
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Location 
Resolution 




User Interactio $( 




Content 
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Content Service 
Provision 







Consumer 



Metadata 

Location resolution 
Content 



Figure 1 : Broadcast model without righits management protection 

Each of the boxes in the model is a function of the TV-Anytime system, and can be implemented in several different 
ways by several different service providers. Different physical implementations of the system will have different 
ordering of functionality in different physical devices (possibly in different locations). The present document gives a 
detailed description of possible system configurations. The arrows in the figure indicate information flows between 
functions, a complete description of these flows can also be found in the present document. 

The broadcast model with a narrowband bi-directional channel supports the feature set listed in TS 102 822-1 [1]. It is a 
pure broadcast model as far as content and associated data is concerned. In this broadcast model only three system 
functions are external to the FDR: content creation, content service provision and access. The bi-directional green link 
between user and service provider can be used to get usage history data or preference data from a consenting user. A 
movie studio or entertainment company could fulfil the role of content creator. A broadcaster would typically handle 
the repackaging, addition of metadata and broadcasting of the content: the content service provision function. A cable or 
satellite operator typically provides the access. The remaining functions reside in the FDR. The FDR can be considered 
as a real device at the consumer's premises that allows him to store and view content. In figure 1 the FDR is the grey 
area encompassing functions search and navigation, location resolution, user interaction, content presentation and local 
storage management. 

This system will allow the user to search, select, locate and acquire content that he likes. The search and selection, 
e.g. by an EFG, will be on the basis of broadcast metadata that advertises the available content. One or more parties can 
put this metadata in the broadcast: the broadcaster, the content creator or a third party. The third party is not modelled in 
figure 1. An extension of this model showing third party operation will be discussed in clause 5.3.1. 

The search and navigation will result after user or automatic selection in a Content Reference ID (CRID). The 
resolution function in the FDR, using the previously obtained content reference ID, results in a physical location of the 
content (e.g. a particular channel and time). Location resolution data must have been broadcast to allow the FDR to 
actually perform this translation from reference ID to in this example physical channel and time. The interfaces on the 
FDR will be subject to the appropriate rights management and protection policies that will be defined in a later version 
of the TV-Anytime specification series. 
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The "full interactive model" features are also described in TS 102 822-1 [1]. In this situation (see figure 2), the 
TV-Anytime consumer has a bi-directional link to other system functions like content service provision or search and 
navigation. In this case the following system functions could be external to the PDR: search and navigation, location 
resolution, content provision, content creation and access. Access will typically be provided by a telecommunications 
operator, there may however also be a broadcast operator providing a broadcast access function. Content creation can be 
done by entertainment companies as in the previous example, web designers or other interactive content designers 
(or even consumers!). Content service provision can be done by several parties e.g. webcasters, broadcasters, portal 
providers etc. The search and navigation function could be provided by a "web-EPG company" or TV -portal company. 
Location resolution could be done by a similar party. This is a new role or party that arises from this scenario. The PDR 
contains Storage, Content Presentation and User Interaction functions in one device. 

The rights management and Protection part visualized in the figure is covered in TS 102 822-5 sub-parts 1 [7] 
and 2 [8], and TS 102 822-7 [12]. 
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Figure 2: Full interactive model 



4.1 Content referencing rationale 



The purpose of content referencing (TS 102 822-4 [6]) is to allow acquisition of a specific instance of a specific item of 
content. For example, if a consumer sees an announcement on TV saying "there will be a new series on "Foxes in the 
cold" around Christmas", he may want to instruct his Personal Digital Recorder (PDR) to record the whole series. 
However the actual time and channel of airing of the episodes might be unknown to the PDR. In fact, the broadcaster 
may not know yet either. Still the viewer will want to make sure at this point that he does not miss the opportunity to 
acquire the content. 

The ability to refer to content (in this example a series of programmes) independent of its location will provide this 
capability desired by the consumer. Whether that location is on a particular broadcast channel on some date and time, or 
on a file server connected to Internet, or wherever. 

In this example, the PDR system would be provided with a reference for the series. In due time, the information 
required to link this reference to the individual episodes will be supplied to the PDR. Subsequently a specific date and 
time for each episode would be provided, so that the PDR would be able to acquire all of them. 



ETSI 



15 



ETSI TS 102 822-2 VI .3.1 (2006-01) 



This example demonstrates the purpose of content referencing - to provide the ability to refer to content independent of 
its location, and the ability to subsequently resolve such a reference into one or more locations where the content can be 
obtained. 



4.2 Phase 1 Metadata rationale 



Users or user-agents want to choose programmes to watch or record. To make that choice they need information like 
what is the title of this programme, what is it about, who are the actors, is it sci-fi? On the other hand, programme 
makers want to attract users to their content, by providing similar information. That is where metadata comes in: it is 
descriptive data about the content the user wants to consume. TV-Anytime content-related metadata (TS 102 822-3 
sub-parts 1 [2] and 2 [3]) is based on that assumption and is therefore largely "attractor" metadata, its goal being to 
provide choice to the user and means to service providers to advertise their content and services. 

Clause 5 describes content referencing and the actors involved. Clause 6 describes the available metadata tools and their 
uses. Example walkthroughs and specific comments describing the dynamic system behaviour in the different processes 
of a TV-Anytime service lifecycle are described in clauses 7 and 8, respectively. 

In complement to descriptive metadata, the purpose of RMPI metadata (TS 102 822-5-1 [7]) is to allow the customer to 
know about the rights associated with content before purchase. The RMPI metadata does not contain the actual rights 
bound to the content but is supposed to be an exact transcription of these rights. 

Table 1 : Phase 1 enabled feature set by TS 102 822-4 [6] and TS 102 822-3-1 [2] 



Model 1 - Broadcast Model 



Support 



Use of EPG to find and capture broadcast content. 



Full 



Search and selection of on-demand content with associated pricing information. 



Full 



Capture and playback of audio, video and data (AVD). 



Full 



Cross linking of A/V content to related content. 



Part 
(see note 1 ) 



Support of consumer preferences. 



Full 



Content can be updated/replaced by newer in-coming versions. 
Support for a variety of broadcast content types. 



Part 
(see note 2) 

Part 
(see note 3) 



Support for all broadcast delivery mechanisms 

IVIulti-user preference support. 

IVIodel 2 - Consumer Response IVIodel. 

Updated listing/capture data can be delivered to "broadcast" analogue personal recorders. 
(via return path or other mechanism). 



Full 

Full 

Support 

Full 



Updated listings/capture data can be delivered to "broadcast" PDRs. 



Full 



Verification of usage of content on PDR. 



Part 
(see note 4) 



Ability to collect usage data. 



Full 



NOTE 1 : 

NOTE 2 
NOTES 
NOTE 4 



Various types of content can be cross-linked using IVIediaLocator (see TS 102 822-3-1 [2]).The 
programme metadata does not contain a CRID for cross-linking to other programmes. 
Entire programmes can be overwritten, but segments of programmes cannot be overwritten. 
See TS 1 02 822-3-1 [2] for a list of supported content types. 
Access to usage data is not specified by the current tools. 



4.3 



Phase 2 Metadata rationale 



4.3.1 New content types 



TV-Anytime Phase 2 supports new content types other than linear audio/video such as games, web pages, music files, 
graphics, data and many other applications. These new content types are treated on their own as non A/V programs 
and/or as components of a package (see the next clause). 
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4.3.2 Packaging 



TV-Anytime Phase 2 defines a technology called packaging (TS 102 822-3-3 [4]) that enables the combination of 
different types of content items such as games, applications and interstitial content with audio, video, still images and 
text, to create a new user experience. 

A package consists of a collection of content items that are intended to be consumed together in some combination to 
provide various consumer experiences. 

For example, one could have an audio-visual French language course with an accompanying word game to better learn 
the French language. 

Package description metadata also provides a mechanism to express the options for consumption depending on usage 
environment (device) and user preference (user). This is further detailed in clause 4.3.3 on targeting. 

Additionally, package description metadata describes synchronization (temporal) and spatial information between 
content items to allow content to be consumed as the content creator intended. Owing to synchronization information, 
multi-stream experience (e.g., multi -camera sports, or alternate audio and video documentaries) can be provided with 
content packaging. 

Figure 3 describes how the Phase 2 packaging technology fits in with the existing TV-Anytime Phase 1 technologies. 
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Figure 3: Packaging and Phase 1 technologies 



4.3.3 Targeting 



In brief, targeting (TS 102 822-3-3 [4]) can be defined as automatically matching and delivering relevant content to 
profiled consumers. There are two types of targeting, which are push targeting and pull targeting. In push targeting, 
broadcasters transmit content with associated metadata to be used in targeted substitution based on user profile, 
preference, usage history, environment and other variables. In pull targeting, an intelligent agent in the PDR uses user 
preferences and other attributes to selectively play and record content. 

In both cases, the user profiles, preferences, usage history, and environment descriptions should be available either in 
the PDR or at a server. 
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4.3.4 Interstitial content 



TV-Anytime Phase 2 TS 102 822-3-4 [5] now targets more advanced concepts such as the ability to perform interstitial 
replacement at playback time based on a number of criteria. The criteria to be used for the control of what content 
should replace what, may be explicitly declared using the schemas defined within TS 102 822-3-4 [5]. 

The interstitial content specification does not attempt to define all the possible ways in which a broadcaster may wish to 
control their system, but provides a generic framework into which a broadcaster can define their own platform specific 
rules, which are used for interstitial replacement control. 



4.3.5 Sharing 



Once content or metadata is acquired it is natural to want to share it in a rightful manner. Users want to tell others about 
interesting content they have found, configure other devices so that they are personalized for them, and perhaps even 
transfer the content to other devices or other users. TV-Anytime Phase 2 specifications include some specific extensions 
to support sharing of metadata. 

The TV-Anytime specifications explicitly support the exchange of user profiles (TS 102 822-6-3 [11]) and the transfer of 
content-related metadata (TS 102 822-8 [13]). The specifications do not cover all use cases regarding sharing of content 
as there are many different ways of implementing this. Indeed, there are several issues of substance that only actual 
implementations can provide detail on how the specifications will be used. 



4.3.6 Remote programming 



The purpose of remote programming (TS 102 822-9 [14]) is to allow the consumer to programme a recording of content 
from another device. 

For example, if the consumer is interested in two programmes which overlap in time and his PDR does not have the 
resources available to cope with this situation, the remote programming specification will allow him to make use of an 
NDR (Network Digital Recorder) to record one of the programmes and make it available later. 

The same solution will be useful when the consumer is out of home and has no possibility to access their home PDR 
from outside. 



4.3.7 Interchange data format 



As illustrated in figure 4, the purpose of the Interchange Data Format specification (TS 102 822-8 [13]) is to allow the 
transfer of TV-Anytime metadata to a TV-Anytime compliant device from another device located in the non-TV-Anytime 
world. 
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Figure 4: Interchange Data Format 

For example, if a consumer can browse an Electronic Programme Guide (EPG) available from a web site and select 
specific content for acquisition, then it would be convenient to obtain part of or all metadata associated with the selected 
content in a format which can be easily integrated with the TV-Anytime metadata already available in the PDR. 

Additionally, the Interchange Data Format also allows to express an action to be done by the PDR on the transferred 
metadata. 

For example, if a consumer selects content from an EPG using its PC in the office, a PDA or a mobile phone, he might 
be interested to send information associated to the content to his PDR at home with an action he wants the PDR to 
perform upon reception: 

- "record" selected content and metadata; 

- record metadata only and "remind" me later; 

- "recommend" the associated content to a friend. 

4.3.8 Coupons 

A coupon is a way to provide value in an electronic form, which can be used to complement / replace money, upon 
purchase of content. Coupons revitalize proven promotional techniques and deliver a competitive advantage to service 
providers who use them. 

TV-Anytime coupon metadata (TS 102 822-3-3 [4]) provides the way to signal the existence of coupon, to explain the 
coupon (value, method, subject of discount, textual-explanation, etc.), and to signal the method to retrieve the coupon. 
The actual realization of a coupon is left to regional / industrial standards or to service providers. 

Coupon metadata support most of existing coupon techniques like discount, two for the price of one, buy three get one 
free, etc. In addition, coupon metadata can express coupons intended to be used upon purchase of non-TV Anytime 
content. 
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5 TV- Anytime content referencing scenarios 

This clause introduces key concepts of content referencing, an extension of the static reference model introduced in 
clause 4 to model third party operation and possible scenarios of issuing and resolving references to items of content. 

5.1 Content referencing key concepts 

The key concept in content referencing (TS 102 822-4 [6]) is the separation of the reference to a content item - the 
CRID - from the information needed to actually retrieve the content item - the locator. The separation provided by the 
CRID enables a one-to-many mapping between content references and the locations of the deliverables. From a system 
perspective, content referencing and resolution lies between search and selection and actually acquiring the content. 
From the content referencing perspective, search and selection yields a CRID, which is resolved into either a number of 
CRIDs or a number of locators (the number may be one). A full discussion of content referencing is beyond the scope 
of the present document; rather it is the intention here to show how content referencing fits into the overall system. In 
the examples below, the syntax of a CRID and the syntax of a locator are employed. The syntax of a CRID is: 

CRID://<authority>/<data> 

Where <authority> takes the form: 

<DNS name> 

<DNS name> is a registered Internet domain name. The <DNS name> is case insensitive and must be a fully qualified 
name according to the rules given by RFC 1591 [17]. 

CRID has been registered on the Official lANA Registry of URI Schemes available at 
www.iana.org/assignments/uri-schemes . The CRID is described in RFC 4078 [19]. 

Some example authority names are: 

www.broadcaster.com 

ISP.net 

www.commerce.com 

The syntax of the locator is: 

<transport mechanism>:<transport system specifio 

The content referencing mechanism employs two key tables. The first is the RAR table that maps the authority that 
issued the CRID to the resolution Service Provider. The second table is the actual resolution table, which maps a CRID 
to another CRID or to a location. The resolution table may also contain information to link a locator to metadata 
describing that instance. Refer to TS 102 822-4 [6] TV-Anytime for a more detailed explanation of the concepts and 
tables involved. 

5.2 Content referencing and unique content identification 

Content referencing is the process of associating a token to a piece of content that represents its location where the 
content can be acquired. It is different from content identification, which creates an identifier that is the same regardless 
of its location. 

A content reference is the token that is used by the PDR to acquire a piece of content once the user (or an agent working 
on their behalf) has selected it. The content reference is the "way pointer" from selection to acquisition. 

A content identifier is an identifier that is created at the point just after the content is created with the idea that this 
identifier will always stay with the content. It allows metadata from multiple sources to all refer to the origination of the 
content. Whilst very useful, a content identifier is not designed for aiding acquisition of the content as it would require 
the (possibly globally centralized) body that created the content identifier to know about every instance of the content, 
and to be informed every time any of these locations change. 

As there are already technologies being designed to fulfil the requirements of a content identifier, the TV-Anytime forum 
have chosen to design a content referencing token as this is an area that requires a global open standard. 
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The TV-Anytime specification uses the CRID as its token to represent the location of content. The CRID can be 
converted into either more CRIDs, or actual locations, by the process of location resolution depicted in figure 5. 




Location resolution 



^ Location(s) / CRID(s) 



Figure 5: The location resolution process 

The idea of a CRID being able to refer to other CRIDs is so that a CRID can represent a grouping of content (which is 
something that a content identifier cannot do). The group CRID can be used for representing any arbitrary group, an 
example of which is an entire series. A group CRID for an entire series would allow the PDR to acquire an entire series 
of programmes by just selecting one CRID to acquire. 

One feature of the group CRID is that it means that many CRIDs may resolve to the same piece of content (as the 
content may be a member of many groups) which means that there might not be one unique CRID per content item. 

The TV-Anytime defined CRID contains information about how to carry out the location resolution process. All CRIDs 
contain two parts, the first part is called an authority (which is the body that created this CRID) and the second part is 
data that has been created by the authority. A piece of information called the resolution authority record provides the 
mapping of resolution authority to the place where location resolution can take place. 

An important feature of the TV-Anytime defined CRID is that it does not require a globally centralized body to assign 
CRIDs, as this was felt was impractical in that it may not scale well (e.g. in an Internet equipped PDR). From talking 
with various broadcasters it was also discovered that an advantage of a non-global registration system is that it allows 
material already in a broadcaster's catalogue to be broadcast without needing to register a globally unique identifier. 

Another advantage of a de-centralized system is that the user can choose an authority which is closest to their personal 
tastes. For example one authority can choose that two programmes are the same, but another authority can specify that 
they are different. E.g. one is a widescreen presentation and the other is a pan and scan presentation of the same film, 
and the user can pick the authority that matches their personal views (e.g. they might consider widescreen and pan and 
scan versions identical). 

5.3 CRID issuing Authority and resolution providers 

The originator of a CRID is the party that actually creates the CRID and assigns it to reference an item of content: the 
Authority. The resolution provider is the party that provides the facility to resolve the CRID into a physical location in 
space and time. Three main actors can originate and resolve content reference identifiers: content creators, content 
creators, and third parties. Third parties are not shown in figure 1, but can be modelled in quite easily. The next clause 
will describe the amended model, after that the possible combinations of actors are discussed. 

5.3.1 Third party extension to static reference model 

Figure 6 shows possible actors in the issuing and resolving of CRIDs. Two of those actors are already in the broadcast 
reference model shown in figure 1, i.e., the content creator and the content creator. Third party operation is not 
explicitly modelled in figure 1 . However, the model can be easily extended to cater for third party provisioning, both for 
CRID and resolution data, as well as metadata. 

This extension is illustrated in figure 6. Only the existing interfaces are modelled in this figure. There may be a need for 
interfaces between the different functions in the content service provision function e.g. to enable the export of 
broadcasting schedules to the metadata provisioning function. 
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Figure 6: Extension to static reference model 

The content service provisioning function in the overall model of figure 1 is split up in a number of different functions: 
a location resolution provision function, a metadata provision function, and a content provision function. For example in 
a service broadcast by broadcast XYZ, where XYZ is provisioning the repackaged content, there could be metadata 
from a third party with more extensive descriptions of XYZ content. This metadata could also be linked to CRIDs 
describing a different clustering of content: e.g. all episodes of a series with a certain actress in them. That same party 
could provide accompanying location resolution data for those CRIDs as well. 

5.4 GRID issuing and resolving scenarios 

In the most straightforward scenario, the originator of a CRID is also the resolution authority for that CRID. However, 
this relationship does not always hold. There are a number of scenarios where the CRID originator does not resolve the 
CRID itself Table 2 depicts all possible CRID originators to CRID resolution authority scenarios. Table 2 shows cases 
that are likely or unlikely to occur in a pure broadcast case. Unlikely in no way implies an impossible scenario. 

Table 2: Originator of a CRID versus resolution of a CRID 





Content creator 
resolves CRID 


Content creator resolves 
CRID 


Third Party resolves 
CRID 


Content creator originates 
CRID 


Likely 


Likely 


Likely 


Content creator originates 
CRID 


Unlikely 


Likely 


Likely 


Third Party originates CRID 


Unlikely 


Unlikely 


Likely 



Clauses 5.4.1 to 5.4.7 describe some of the possible scenarios in more detail. 

5.4.1 CRID originated by content creator, resolved by content creator 

In this simple scenario, the content creator creates the content and creates a CRID to reference that piece of content. The 
content creator also provides the resolving information to find that particular piece of content. 

In the broadcast case, suppose the content creator is not the broadcaster, and the content in question is a drama entitled 
"Most Moving Drama Ever". The authority syntax might then be: 

content.com 

The CRID itself might take the form: 

CRID://content.coni/drama/MostMovingDramaEver 
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The string "drama/MostMovingDramaEver" is meaningful to the authority, i.e., the authority will be able to resolve this 
CRID when it is asked to do so. The content creator, having created the drama programme and having assigned it a 
CRID, needs to be able to broadcast the location resolution information to the PDR. This means it needs to have access 
to the broadcast channel and schedule information of the relevant broadcaster(s) involved. In the pure broadcast 
scenario, because there is no return channel, the location resolution takes place in the PDR itself Finally, the content is 
broadcast and can be recorded on the local storage device and consumed later, or can be viewed at the time of 
broadcast. 

When the broadcaster is also the content creator the scenario is simpler and described in clause 5.4.4. 

5.4.2 CRID originated by content creator, resolved by content creator 

In this scenario, the content creator creates the content with an associated CRID. The content creator is the resolution 
service provider. 

Supposing the content creator is a motion picture studio, and the content in question is an action movie entitled "Best 
Action Movie Ever". The content creator is a broadcaster. In this case the content creator is acting as a proxy for the 
content creator. The content creator creates a CRID. It might look like this: 

CRID://moviestudio.coiii/movies/BestActionMovieEver 

The broadcaster, having purchased the movie from the studio for airing and having also acquired the CRID, broadcasts 
the location resolution information to the PDR. This information is contained in the "Resolution Tables" that map the 
CRID to the location. Also broadcast to the PDR are the Resolution Authority Records, one of which effectively 
includes a redirect, a record where the authority name and resolution service provider are different. In this example 
there is a RAR where the authority name is "moviestudio.com" and the resolution provider is "broadcaster.com". 

In a uni-directional network, the location resolution takes place in the PDR. The consumer selects "Best Action Movie 
Ever" during some navigation or search process. The location resolution engine, having looked up the appropriate RAR, 
resolves the CRID whose authority is "moviestudio.com" by using the resolution service provider "broadcaster.com". 
The resolution service provided by "broadcaster.com" resolves the CRID to the actual location, the time and channel of 
the broadcast in the context of the service provider. 

Finally, the movie is broadcast and can be recorded on the local storage device and consumed later, or can be viewed at 
the time of broadcast. 

5.4.3 CRID originated by content creator, resolved by third party 

In this scenario, the content creator creates the content and associated CRID. A third party resolves the CRID. 

Supposing the content creator is a documentary production company, and the content in question is a documentary 
entitled "Incredible Documentary". Several broadcasters will carry this documentary over a period of time. In terms of 
location resolution the third party is acting as a proxy for the content creator. The production company creates a CRID. 
It might look like this: 

CRID://documaker.coin/IncredibleDocumentary 

The third party might be an EPG service. The advantage of the third party in this case is that it can look across all 
service providers in the multiplex to resolve a CRID. The third party inserts the location resolution tables into the 
broadcast stream. Also inserted into the broadcast stream are the RARs, one of which contains the authority name 
"documaker.com" and the resolution service provider "res-service.ecg.com". 

In a uni-directional network, the location resolution takes place in the PDR. The consumer selects "Incredible 
Documentary" during some navigation or search process. The location resolution engine searches the table of RARs and 
finds the one whose authority name matches the authority name in the CRID, in this example "documaker.com". The 
engine then uses the URL contained in the record to find the actual location resolution tables. In this way the CRID is 
resolved to a locator e.g.: 

transport:channel5@8.00 

Finally, the content is broadcast and can be recorded on the local storage device and consumed later, or can be viewed 
at the time of broadcast. 
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5.4.4 GRID originated by content creator, resolved by content creator 

In this scenario, the content creator acquires content and assigns its own CRID to reference that content. The content 
creator is also the resolution service provider. 

The content creator could be a broadcaster, and the content in question is the movie "Best Action Movie Ever" from a 
motion picture studio. The motion picture studio, the content creator, may very well have its own CRID referencing the 
movie, but the content creator decides not to use this. The broadcasters CRID might look like this: 

CRID://broadcaster.coin/movies/BestActionMovieEver 

The broadcaster inserts the location resolution tables into the broadcast stream. Also inserted into the broadcast stream 
are the RARs, one of which contains the authority name "broadcaster.com" and the resolution service provider 
"broadcaster.com" . 

In a uni-directional network, the location resolution takes place in the PDR. The consumer selects "Best Action Movie 
Ever" during some navigation or search process. The location resolution engine searches the table of RARs and finds 
the one whose authority name matches the authority name in the CRID, in this example "broadcaster.com". The engine 
then uses the URL contained in the record to find the actual location resolution tables. In this way the CRID is resolved 
to a locator, e.g.: 

transport:channel9@21.30 

Finally, the content is broadcast and can be recorded on the local storage device and consumed later, or can be viewed 
at the time of broadcast. 

5.4.5 CRID originated by content creator, resolved by third party 

In this scenario, the content creator creates a CRID associated to content, but a third party is delegated to resolve the 
CRID. The content creator could be a broadcaster. Suppose the content in question is the movie "Best Comedy Movie 
Ever". The motion picture studio, the content creator of the movie, may very well have its own CRID referencing the 
movie, but the content creator decides not to use this. The broadcaster creates a CRID that might look like: 

CRID://broadcaster.coin/movies/BestComedyMovieEver 

The third party might be a trusted agent such as an EPG service provider. Either the broadcaster or the third party may 
create the location resolution tables as well as the RARs, one of which contains the name of the authority, 
"broadcaster.com", along with the name of the resolution service provider, "res-service.ecg.com". The RARs can be 
inserted into the broadcast. Thus, in terms of location resolution the third party is acting as a proxy for the content 
creator, broadcaster.com. In a uni-directional network, the location resolution takes place in the PDR, while in a 
bi-directional network, the location resolution may take place on the server side. The consumer selects, as a result of 
some navigation or search process, "Best Comedy Movie Ever". The CRID resolution engine searches the table of 
RARs and finds the entry whose authority name matches the authority name in the CRID, "broadcaster.com" in this 
example, which is resolved in turn to give "res-service.ecg.com". The engine then uses this resolved information to find 
the actual location resolution tables, which are provided by "res-service.ecg.com". In this way, the CRID is resolved and 
the locator for the CRID is obtained. The content can now be captured. 

5.4.6 CRID originated by third party, resolved by content creator 

In this scenario, a third party service creates e.g. a group CRID that references other CRIDs that in turn reference actual 
content. The third party could be an aggregator of some description. The content creator agrees to be the resolution 
service provider for this third party because the third party service is particularly valuable. 

Suppose the third party provides a CRID referencing all episodes of the "Star Journey" science fiction series. The CRID 
might look like this: 

CRID://StarJourneyAggregator.coin/AllEpisodesOfStarJourney 

The broadcaster provides a Resolution Authority Record (RAR) containing the authority name 
"StarJourneyAggregator.com" and the resolution provider "broadcaster.com". 
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The consumer, using some search and navigation process comes across the "All Episodes of Star Journey" item. The 
PDR looks up authority it finds in the GRID for this item. It finds that the resolution service provider is 
"broadcaster.com" and uses the URL to find the resolution tables. It resolves the GRID into a list of other GRIDs: 

CRID://broadcaster.coin/StarJourneyEpisodel 

CRID://broadcaster.coin/StarJourneyEpisode2 

CRID://broadcaster.coin/StarJourneyEpisode3 

In this example, the broadcaster issued the returned GRIDs, however the third party could also have its own GRIDs for 
these episodes that a broadcaster knows how to resolve. 

The various episodes are presented to the viewer for selection. The viewer selects "Star Journey Episode 2" and again 
the engine looks up the authority name in the RAR table. It finds that authority name "broadcaster.com" maps to 
resolution provider "broadcaster.com", and subsequently resolves the GRID to a list of alternate locations e.g.: 

transport :channel9@21.30 

transport:channel5@9.15 

The most appropriate location is chosen depending on such factors as how soon the viewer wishes to watch the 
programme, recording conflicts if the programme is to be saved to local storage, the cost of one location versus the 
other etc. 

Finally, the content is broadcast and can be recorded on the local storage device and consumed later, or can be viewed 
at the time of broadcast. 

5.4.7 GRID originated by tinird party, GRID resolved by tinird party 

In this scenario, a third party service creates e.g. a group GRID and references other GRIDs that in turn reference actual 
content. The third party is an aggregator of some description. The same or another third party is also the resolution 
service provider. 

Suppose the third party provides a GRID referencing all nature documentaries on all channels within a multiplex. The 
GRID might look like this: 

CRID://Aggregator.coin/AllNatureDocumentaries 

The third party provides a Resolution Authority Record (Rar) containing the authority name "Aggregator.com" and the 
resolution provider "Aggregator.com". This is broadcast to the PDR along with the resolution tables, tables that the 
third party collates from schedule metadata it collects from all the content creators in the multiplex. 

The consumer comes across the "All Nature Documentaries" item in their EPG. The PDR looks up the authority it finds 
in the GRID for this item. It finds that the resolution service provider is "Aggregator.com" and uses the URL to find the 
resolution tables. It resolves the GRID into a list of other GRIDs: 

CRID://Aggregator.coin/FoxesInTheWild 

GRID:// Aggregator.com/OceansOfThe World 

GRID :// Aggregator .com/TheMapleTree 

The various programmes are presented to the viewer for selection. The viewer selects "Oceans of the World" and again 
the engine looks up the authority name in the RAR table. It finds that authority name "Aggregator.com" maps to 
resolution provider "Aggregator.com", and subsequently resolves the GRID to a list of alternate locations e.g.: 

transport:channel2@ 17.30 

transport :channel7@21.00 

The most appropriate location is chosen depending on such factors as how soon the viewer wishes to watch the 
programme, recording conflicts if the programme is to be saved to local storage, the cost of one location versus the 
other. 



£75/ 



25 ETSI TS 1 02 822-2 V1 .3.1 (2006-01 ) 

Finally, the content is broadcast and can be recorded on the local storage device and consumed later, or can be viewed 
at the time of broadcast. 

5.5 Example of coding an ISAN using a GRID 

The ISO and SMPTE/ATSC have been actively working on the creation of an International Standard Audiovisual 
Number (ISAN). The goal of the ISAN is to uniquely identify completed audio-visual works, episodes of a work, 
versions of a work, and related parts of versions of a work (such as audio and subtitling tracks). In contrast with a 
CRID, the ISAN remains the same regardless of the provider of that content and would further allow comparisons 
between IS ANs to determine that two pieces of content differ only by being a different version of the same root work or 
are different episodes of the same series. 

The TV-Anytime Forum recognizes that some metadata and content providers have expressed interest in using the ISAN 
to identify the programmes they provide or reference in metadata. As such, the following CRID format is proposed to 
enable a CRID to be built using a known ISAN. 

An example CRID incorporating an ISAN will look like: CRID://<authority>/isan<ISAN according to ISO 15706 
[18]>In this example the <authority> portion is as specified in TS 102 822-4 [6] and the <data> portion of the CRID is 
an ISAN, prefixed with the fixed string "isan". In this case the normal use and semantics of the CRID are preserved. 
Namely, to convert this CRID into one or more location records the PDR contacts a location resolution service serving 
the Resolution Authority named in the <authority> portion of the CRID and passes the <data> portion, which in this 
case is an ISAN. However, because the data portion is clearly identified as an ISAN it also enables the PDR to make 
comparisons between CRIDs to determine if the referenced content is identical, different by version, or different by 
episode. 

It is important to note that there is a significant difference between a CRID that is issued by a resolution authority and 
one that is constructed by the user interaction functionality in the PDR. There is an intention that a CRID that is issued 
will always be resolved by the relevant authority, whereas resolution of a constructed CRID is entirely speculative: one 
cannot rely on getting the location of the requested content. 

Any unique ID for content can be used in a similar way as the ISAN in the above examples. 

5.6 The relation between CRID and instance metadata 

Instance description metadata is used to describe meaningful differences between specific instances of the same content 
i.e. instances of content that share the same CRID. For example, two instances of the same film where the instance 
description metadata indicates that one is in the original 16:9 aspect ratio and the other is in 4:3. Instance description 
metadata is linked to a particular event-related instance of content. For the full specification of instance description 
metadata see TS 102 822-3-1 [2] and TS 102 822-3-2 [3]. For a discussion of instance description metadata in the 
System context, see clause 6.3.2. 

The TV-Anytime CRID is used to select and acquire an item of content independent of any particular location (time or 
place). In some cases however, the consumer may wish to acquire a location dependent version of a piece of content 
e.g. the 16:9 version of the film. To enable this functionality, the content referencing specification - TS 102 822-4 [6] - 
details an optional identifier called an Instance Metadata Identifier. This identifier is only guaranteed to be unique 
within the scope of the CRID to which it has been assigned. So it is permissible to assign the same identifier value to 
different CRIDs. 

The PDR can use the Instance Metadata Identifier to track changes in the scheduling of a specific instance of a piece of 
content. The following example illustrates the problem and the solution. 

Suppose a PDR resolves a CRID: 

crid://broadcaster.coin/GreatMovie 

to two locators: 

dvb://123.5ac.3be;3e45@2001-12-07T12:00:00.00-H01P02:10 
dvb://487.2ee.3be;9e26@2001-12-09T12:00:00.00-H01P02:10 
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Suppose further that the first locator is the 16:9 version of GreatMovie, and the second is the 4:3 version. The viewer 
decides that they want the 16:9 version, but it is not on for a couple of days yet so the PDR makes a note to acquire it. 
As it comes closer to the scheduled time (as indicated by the locator), the PDR again resolves the GRID to see if the 
time the film is going to be on has changed. This time the location resolution process yields two locators: 

dvb://123.5ac.3be;3e45@2001-12-07T14:00:00.00+01P02:10 

dvb://487.2ee.3be;9e26@2001-12-09T09:00:00.00+01P02:10 

Both the 16:9 version and the 4:3 version have been rescheduled, and without Instance Metadata Identifiers, the PDR 
would not be able to tell which is the location of the specific instance (the 16:9 instance) the viewer wants acquired. 

With the use of Instance Metadata Identifiers, each of the original two locators would be assigned an identifier. The 
Instance Metadata Identifier appears in the location resolution tables and also appears in the corresponding instance 
metadata. So the first resolution of GRID: 

crid://broadcaster.coiii/GreatMovie 

yields: 



dvb://1 23.5ac.3be;3e45@2001 -1 2-07T1 2:00:00.00+01 P02:1 


imi:broadcaster.com/1 


dvb://487.2ee.3be;9e26@2001 -1 2-09T1 2:00:00.00+01 P02:1 


imi:broadcaster.com/2 



The viewer selects the 16:9 version for acquisition, and this time the PDR takes note of the Instance Metadata Identifier 
as well as the locator. As it gets closer to the scheduled time, the PDR once again resolves the GRID, and the location 
resolution process yields the following: 



dvb://1 23.5ac.3be;3e45@2001 -1 2-07T1 4:00:00.00+01 P02:1 


imi:broadcaster.com/1 


dvb://487.2ee.3be;9e26@2001 -1 2-09T09:00:00.00+01 P02:1 


imi:broadcaster.com/2 



Once again the PDR is unable to tell which locator is the 16:9 instance of the film by just examining the locators, but 
this time it can tell that the first locator is the right one because the Instance Metadata Identifier has not changed. It is 
the fact that the Instance Metadata Identifier remains unchanged across schedule changes that solves this particular 
problem for the PDR. 

The use of the IMI might lead to unexpected effects. Gonsider the following. A consumer wishes to record the earliest 
showing of a certain programme. If he uses the IMI to express that and the locator connected to that IMI changes, it is 
possible that the PDR will not record the earliest showing. 

As in the example above, suppose the user expresses that he wants to record the programme with 
imi:broadcaster.com/l, since this currently denotes the first showing: 



dvb://1 23.5ac.3be;3e45@2001 -1 2-07T1 9:00:00.00+01 P02:1 


imi:broadcaster.com/1 


dvb://487.2ee.3be;9e26@2001 -1 2-07T23:00:00.00+01 P02:1 


imi:broadcaster.com/2 



If the programme gets rescheduled this might no longer be the case: 



dvb://1 23.5ac.3be;3e45@2001 -1 2-08T1 9:00:00.00+01 P02:1 


imi:broadcaster.com/1 


dvb://487.2ee.3be;9e26@2001 -1 2-07T23:00:00.00+01 P02:1 


imi:broadcaster.com/2 



5.7 GRID lifecycle 



An authority who creates GRIDs and assigns them to pieces of content has the choice of keeping this assignment 
permanent, or making it temporary and re-assigning GRIDs to completely different pieces of content at a later date. 

Assigning a GRID to a piece of content in a permanent manner has the advantage of allowing a PDR to always assume 
that every time it encounters the GRID it is referring to the same piece of content. However, this permanent assignment 
has the disadvantage that the GRID authority will need to keep records of this assignment to make sure it never re-uses 
the GRID for a different piece of content. 
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When CRIDs are re-used to refer to different pieces of content, there are a number of problems that may occur. The 
following scenarios demonstrate some of these problems: 

1) A programme is being repeated a number of weeks apart. The first broadcast is selected for recording by a 
software agent whilst the user is on holiday. On returning from the holiday the user sees a trailer for the repeat 
(and does not necessarily know that it has already been recorded), which he selects to be recorded. The PDR 
obtains the programme GRID from the trailer, which it recognizes as the same GRID as one previously 
captured. The PDR now has two choices: 

a) Assume that the GRID refers to the same content concept as previously captured. There is therefore no 
need to record the programme and so the user should be informed that the programme is already 
available for viewing. If, in fact, the GRID has been reused to refer to a different programme concept in 
the intervening period, the PDR will fail to record the expected content. 

b) Assume that the trailer GRID has been reused since the previous one was captured and that the newly 
selected programme should be recorded. In this case, if the trailer GRID did still refer to the same content 
concept, the programme would be recorded twice and the PDR will have missed an opportunity to let the 
user watch the content sooner than it might otherwise have done so. 

2) A programme has been recorded and the user chooses to watch it for the first time some months later. The 
cached metadata indicates that segmentation data is available (but the PDR did not originally acquire it). The 
user requests the segmented version, and to do this the PDR attempts to obtain the segmentation data from a 
TV-Anytime web service. If the GRID has been reused it is possible that segmentation data will be downloaded 
for the wrong content resulting in a confused user. 

3) A content creator has issued a GRID and a third party web service offers enhanced metadata (such as 
programme reviews) on that content using the GRID provided by the content creator. If the content creator 
reuses the GRID it would cause programme reviews not to match the other metadata for the piece of content. 

4) A PDR caches the metadata for a GRID along with the content. When the viewer comes to watch the content, 
the PDR sees that the content has parent GRIDs associated with it. The PDR would like to offer the user the 
chance to exploit this data - i.e. offer functionality like "record the whole series", "record the next 
programme". If the parent GRID has been re-assigned to a different programme grouping concept since it was 
originally issued, the PDR would acquire the incorrect series. 

When GRIDs are assigned forever, there are also issues that need consideration. The following scenarios illustrate these 
issues: 

1) If GRIDs are assigned forever the GRID author must maintain a history of all GRIDs issued, and knowledge of 
all metadata associated with the GRIDs. This may not be practicable for the following reasons: 

a) GRID authors working with broadcast schedules that extend over a short time interval may be unable to 
take into account all GRID allocations made during past scheduling/GRID authoring activities without 
incurring extra cost overheads that may be considered commercially unattractive. 

b) Allocation of GRID values may be made by resolution data authoring systems that will become obsolete 
or require re-setting from time to time. 

c) The GRID authority may decide to start issuing GRIDs for many items of content, such as trailers or 
adverts, to support independent acquisition of these short pieces of material. The nature of these 
short-lived publications may mean that GRID tracking by the author is not appropriate. 

2) In many cases, several GRIDs may point to the same content. So, even if GRIDs are assigned forever, the 
content provider and user should still be encouraged to fully utilize the programme metadata as a means to 
describe the content, rather than just rely on the GRID. 

3) Accidental re-use is likely to occur in a working system. Therefore a policy of reliance on non re-use may 
result in unpredictable or unknown behaviour, e.g. incorrect or missed acquisition of content. 

As a result of the issues arising from the choice of GRID authoring policy, a working assumption for the unidirectional 
broadcast system would be to show caution when considering deliberately reusing GRIDs over short time intervals. 

In order to assist receiving equipment in managing content and metadata, a GRID shall not be deliberately re-purposed 
during its lifetime. 
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The lifetime starts when the CRID is issued and is infinite, unless the CRID is known to be of a transient nature in 
which case this shall be signalled by the underlying transport. Such a CRID will have an expiry date defined 
recursively, as follows: 

• Expiry date of a locator: 

For scheduled content, the expiry date is given by the "start" and "duration" as expressed by the locator. 
For on demand content, it is given by the end of the availability window. 

• The expiry date of a CRID is the maximum (latest) of the expiry dates the CRID resolves into. 

Optionally the CRID authority may extend the expiry date of a transient CRID by a given duration (e.g. 7 days 
or 14 days or a year). 

For reasons of transport efficiency it is recommended that this extension to the expiry date is signalled by the 
underlying transport for each CRID authority. 

In this way a service provider may introduce different expiry policies on different services through the use of different 
CRID authority names. 

NOTE 1 : CRIDs known to be transient that are re-introduced after a previous expiry date has passed cannot be 
guaranteed to refer to the same content and, therefore, are to be considered new. 

NOTE 2: If in the resolution of a CRID a re-resolve date is set, the CRID is still active and the expiry date cannot 
be determined by the receiving equipment, but is known to be after the re-resolve date. 

NOTE 3: The expiry date of transient CRIDs is derived from the locator with the latest time. This is only known 
when all resolution information has been conveyed as signalled by the "complete" attribute of the Result 
element in the ContentReferencingTable. 

5.8 Harmonization of TS 1 02 822-4 and TS 1 02 822-6 

TS 102 822-4 [6] specifies the requirements for unidirectional and bi-directional resolution of content references. It also 
provides an HTTP binding for bi-directional resolution over IP based networks. TS 102 822-6-1 [9] and 
TS 102 822-6-2 [10] meets all the requirements of TS 102 822-4 [6], and also provides a rich set of metadata queries. 
TS 102 822-6-1 [9] provides all the features of the HTTP binding in TS 102 822-4 [6] using a SOAP binding. 

It is recommended that new server and client implementers using IP networks use the protocols defined in 

TS 102 822-6-1 [9] and TS 102 822-6-2 [10] in preference to TS 102 822-4 [6]. Note that this does not apply to the 

DNS based discovery of content referencing servers, as this is not superseded in TS 102 822-6-1 [9] and 

TS 102 822-6-2 [10]. TS 102 822-6-1 [9] and TS 102 822-6-2 [10] extends this DNS discovery mechanism to include 

metadata servers. 



6 Metadata 

6.1 Introduction 

Metadata is generally defined as "data about data". Within the TV-Anytime environment, the most visible parts of 
metadata are the attractors/descriptors or hyperlinks used in Electronic Programme Guides (EPGs), or in Web pages. 
This is the information that the consumer or agent will use to decide whether or not to acquire a particular piece of 
content. 

The TV-Anytime metadata system allows the consumer to find, navigate and manage content from a variety of internal 
and external sources including, for example, enhanced broadcast, interactive TV, Internet and local storage. It defines a 
standard way to describe consumer profiles including search preferences to facilitate automatic filtering and acquisition 
of content by agents on behalf of the consumer. 
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There is a need to associate metadata with content to facihtate human and automated searching for content of interest. 
Such metadata includes descriptive elements and attractors to aid the search process as well as elements essential to the 
acquisition, capture and presentation processes; content rights, formats, duration, etc. Many of these descriptive 
elements can be found in electronic programme guides and Web pages. 

The process of creation and evolution of metadata for an individual content item may involve many organizations 
during the course of creation, distribution and delivery to the consumer. Thus, there is a clear need to define a common 
metadata framework and a standard set of metadata elements in order to ensure a high level of interoperability within 
the chain from content creation to content delivery. 

6.2 XML - a common representation format 

For the purpose of interoperability, the TV-Anytime Forum has adopted XML as the common representation format for 
documentation of metadata. XML offers many advantages: it allows for extensibility, supports the separation of data 
from the application, and is widely used. In addition, powerful XML tools are now available such as XSL (XML 
Stylesheets), XQL (XML Query Language), and XML databases that can be used to process and manage XML data. As 
a textual format, XML tends to be rather verbose; however, a number of mechanisms are being developed to reduce the 
bandwidth when necessary. It is important to note that the XML representation of a TV-Anytime document is just that, a 
representation. It is one possible representation of the metadata; it is not the only representation of the metadata. There 
is no assumption that TV-Anytime metadata must be represented in XML format. Metadata could be represented by an 
optimized binary format to conserve bandwidth and aid rapid processing and mapping to a database. It is strongly 
recommended that if XML is used as exchange syntax for TV-Anytime metadata, then that XML should conform to the 
TV-Anytime Schema. This has obvious advantages in the business-2-business realm in addition to the 
business-2-consumer realm. 

The following clauses introduce the TV-Anytime metadata schemas. They also provide snippets of XML instance 
documents. Basic knowledge of XML is needed in order to understand the following clauses. 

6.3 The TV-Anytime metadata high level documents 

All TV-Anytime metadata instance documents are grouped under a root element called "TVAMain". 

6.3.1 Metadata structure 

There are six basic kinds of metadata that a "TVAMain" element groups: 

• Content description metadata. 

• Instance description metadata. 

• Consumer metadata. 

• Segmentation metadata. 

• Metadata origination information metadata. 

• Interstitial and targeting metadata. 

The diagram in figure 7 illustrates this relationship. 
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Figure 7: TV-Anytime documents with "TVA lUlain" as a root element 

6.3.2 Phase 1 Metadata 

6.3.2.1 Content description metadata 

Content description metadata is divided into four areas: 

Descriptions of items of content e.g. television programmes. These descriptions are held in the 
ProgramlnformationTable. They include things like the title of the programme, a synopsis, the genres it falls 
under and a list of keywords that can be used to match a search. The following example is a 
ProgramlnformationTable containing a single Programlnformation element. The example is not exhaustive. 

<ProgramInf ormationTable> 

<ProgramIn format ion programId="crid : //hbc . com/foxes/ episode 11 "> 
<BasicDescription> 

<Title type="main"> 

The one where Fox jumps in the Potomac 
</Title> 
<Synopsis> 

Fox goes to Washington and jumps in the Potomac 
</SYnopsis> 

<KeYword>Fox</Keyword> 
<Keyword>Washington</Keyword> 
<Keyword>Potomac</Keyword> 

< Gen re href ="urn : tva : metadata : cs : Format CS :2005:3.5.7.3" type="main" /> 
</BasicDescription> 

<OtherIdentifier>guid: / /e41a-b4 5 6-a8 7 6-3e4 9</0ther Identifier > 
<OtherIdentif ier>urn :mpeg :mpeg21 : 
diid:isan:2 9ef-94ba-53c4-3e7a-4ce8-e-5a4 5-98ec-f</OtherIdentifier> 
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<MemberOf crid = "crid: //hbc . com/foxes/all" index = "H" xsi:type 
"EpisodeOfTYpe"/> 
</ProgramInf ormation> 
</ProgramInformationTable> 



Descriptions of groups of related items of content e.g. all episodes of "Foxes in the Wild". These descriptions are held 
in the GroupInformationTable. The following example is a GroupInformationTable containing a single 
Programlnformation element. The example is not exhaustive . 



<GroupIn format ionTable> 

<GroupIn format ion groupId="crid : //hbc . com/f oxes/all"> 

<GroupType xsi : type="ProgramGroupTypeTYpe" value="series"/> 
<BasicDescription> 

<Title type="main">All episodes of Foxes ever</Title> 
<Synopsis>More Foxes than you can handle</Synopsis> 
<Keyword>Foxes</Keyword> 
<Keyword>all</Keyword> 

< Gen re href ="urn : tva : metadata : cs : Format OS :2005:3.5.7" type="main" /> 
</BasicDescription> 

<MemberOf xsi : type= "Member Of Type" crid="crid: //hbc . com/ comedy /all" /> 
</GroupInf ormation> 
</GroupInf ormationTable> 
</ProgramDescription>- 



A mapping of cast members to unique identifiers. The identifiers can be used in other metadata instances making 
searching easier. These descriptions are held in the CreditsInformationTable. 

Purchase information. This is held in the PurchaselnformationTable. 

Critical reviews of items of content. These descriptions are held in the ProgramReviewTable. 

6.3.2.2 Instance description metadata 

Instance description metadata is divided into two areas: 

Descriptions of particular instances (locations) of content. These descriptions are held in the 
ProgramLocationTable. This metadata contains the scheduled time, but note that using this representation is 
not the preferred means of determining locations. The preferred means of determining locations is by resolving 
a CRID using the location resolution mechanism. 

ProgramLocationTable contains records (elements) that are derived from ProgramLocationType (this is a base 
type, it is not instantiated directly, see TS 102 822-3-1 [2] and TS 102 822-3-2 [3]): 



<ProgramDescription> 




<ProgramLocationTable> 




<BroadcastEvent serviceIDRef="hbcl00022311"> 




<Program crid="crid: //hbc . com/f oxes/episodell 


'/> 


<ProgramURL>dvb : //I . 4ee2 . 3f 5/</ProgramURL> 




<PublishedStartTime>2001-04-07T19:00:00.00+01 


00</PublishedStartTime> 


<PublishedDuration>PT6H</PublishedDuration> 




<Live value="f alse"/> 




<Repeat value="true"/> 




<FirstShowing value="f alse" /> 




<LastShowing value=" false" /> 




<Free value="false"/> 




< /Broadcast Event > 




</ProgramLocationTable> 




</ProgramDescription> 
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It is possible to also include a BasicDescription element within BroadcastEvent. One use of this element is 
where an actor appearing in the programme has recently died, and the particular showing of the programme is 
a tribute. This extra information becomes an attractor for the programme. The synopsis of the programme is 
altered to reflect the fact that the programme features the deceased actor. It is more appropriate to change the 
synopsis for the instance, rather than the synopsis in the metadata attached to the GRID, as the "tribute" 
showing has a limited lifespan. Another use is where different instances have different technical attributes, 
such as aspect ratio or audio or video coding. 

Optionally an IMI can be used for each BroadcastEvent that can be used to link the instance metadata to the 
content referencing information. 

Optionally, also here purchase information can be carried. 

Descriptions of services within a system. These descriptions are held in the ServicelnformationTable. Each 
description is encapsulated by a Servicelnformation element, illustrated in the example: 

<ProgramDescription> 
< Service In formationTable> 
<Service Information serviceld="hbcl 00022311 "> 
<Name>HBC Channel 1</Name> 
<Owner>HBC</ Owner > 
< /Service In formation> 

Oervice Information serviceld="kgt 1042062318 "> 
<Name>KGT Channel 9</Name> 
<Owner>KGT</ Owner > 
< /Service In formation> 
< /Service I nformationTable> 
</ProgramDescription> 



6.3.2.3 Consumer metadata 

Consumer metadata is divided into a number of areas: 

Details of a user's preferences or profile. This information is delivered by the UserPreferences description 
scheme, which provides rich representations of the particular types of content preferred or requested by the 
user. These descriptions are closely correlated with media descriptions, and thus enable users to efficiently 
search, filter, select and consume desired content. In the following example, the user ("Robert") prefers news 
programmes in English, when he is in Japan. The user also prefers comedy films reviewed and ranked by a 
particular film critic, as well as movies rated PG-13 by the MPAA (Motion Picture Association of America). 
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<UserDescription> 
<UserPreferences> 

<mpeg7 :UserIdentif ier protected="true"> 

<mpeg7 :Name xml : lang="en">Robert</mpeg7 : Name> 
</mpeg7 :UserIdentif ier> 
<mpeg7 : FilteringAndSearchPref erences> 

<mpeg7 :Classif icationPreferences pref erenceValue="10"> 
<mpeg7 : Language>en</mpeg7 : Language> 

<mpeg7 : Genre href ="urn : tva : metadata : cs : Format CS :2005:3.1.1"/> 
</mpeg7 : Classif icationPref erences> 
<mpeg7 :ClassificationP references pref erenceValue=" 12 "> 

<mpeg7 : Genre href ="urn : tva : metadata : FormatCS :2005:3.5.7"/> 
<mpeg7 : Review> 
<mpeg7 : Rating> 

<mpeg7 : RatingValue>7</mpeg7 : RatingValue> 
<mpeg7 : RatingScheme best="10" worst="l" 
style="higherBetter " /> 
</mpeg7 : Rating> 

<mpeg7 : Reviewer xsi : type="mpeg7 : PersonType"> 
<mpeg7 : Name> 

<mpeg7 :FamilyName>Ebert</mpeg7 :FamilyName> 
<mpeg7 : GivenName>Roger</mpeg7 : GivenName> 
</mpeg7 :Name> 
</mpeg7 : Reviewer> 
</mpeg7 : Review> 
<mpeg7 :ParentalGuidance> 
<mpeg7 :ParentalRating 

href="urn:mpeg:MPAAParentalRatingCS:PG-13"> 
<mpeg7 : Name>PG-13</mpeg7 : Name> 
</mpeg7 :ParentalRating> 
<mpeg7 :Region>us</mpeg7 :Region> 
</mpeg7 :ParentalGuidance> 
</mpeg7 : Classif icationPref erences> 
<mpeg7 :Pref erenceCondition> 
<mpeg7 :Place> 

<mpeg7 :Name xml : lang="en">Tokyo</mpeg7 :Name> 
<mpeg7 :Region> jp</mpeg7 :Region> 
</mpeg7 : Place> 
</mpeg7 :PreferenceCondition> 
</mpeg7 : FilteringAndSearchPref erences> 
</UserPreferences> 
</UserDescription> 



Details of a user's "click data", e.g. the actual usage history of a user's actions. UsageHistory description 
scheme provides a list of the actions carried out by the user over an observation period. This information can 
subsequently be used by automatic analysis methods to generate user preferences. An extensive example can 
be found in annex A. 

6.3.3 Phase 2 metadata 
6.3.3.1 Schema overview 

The Phase 2 TV-Anytime metadata schema is a backwards-compatible extension of the Phase 1 schema. It extends Phase 
1 datatypes for content description and user description and makes use of datatypes imported from MPEG -21 to enable 
new areas of functionality. It also extends the TV-Anytime root document type, TVAMainType, to enable publication of 
metadata described using the new datatypes. 

All of the new datatypes are declared within a single namespace (with the identifier "tva2"). The schema for this 
namespace imports all of the phase one schemas (for the "xml", "tva" and "mpeg7") as well as those for MPEG-21 
(indicated by the "mpeg21" namespace identifier). It also imports the namespace ("rmpi") for the companion 
TV-Anytime specification TS 102 822-5-1 [7] for rights management and Protection Information (RMPI). 

It is important to note that the extensions within the tva2 namespace are modular and that this offers great potential 
flexibility in implementation. This reflects the heterogeneous nature of the business requirements of Phase 2 which go a 
long way beyond the traditional broadcast model that is at the heart of Phase 1 . 
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The first part of the schema contains description tools for new types of content, other than audiovisual content 
(e.g. applications), and for properties of content that are determined by the context in which they are used 
(e.g. education). The primary intention is to be able to describe other forms of content that may be associated with 
audiovisual content, and specialist areas in which an enhanced audiovisual service may be deployed. 

There is no pretension to being a metadata standard for the detailed description of all possible content services from 
hardcopy libraries to CD collections. TV-Anytime has maintained its focus on primarily audiovisual digital content 
services, but extended it to take into account the implications of bi-directionality and digital distribution methods other 
than traditional broadcast. In this spirit, its content description capabilities have also been extended to enable content 
targeting, coupon description and description of content packages (composite content where several components come 
together to give the user a particular experience). 

Targeting of content, including promotional trailers and advertisements, can, using the new description tools, take into 
account user preferences, usage history, personal characteristics (biographic and accessibility) and usage environments 
(terminals, networks and natural environmental characteristics). 

Coupon description offers content providers the tools to associate specific content offerings with special pricing offers. 
By combining the coupon description and targeting tools a wide range of interesting new business models is made 
possible. 

The content package description tools also enable a broad spectrum of new possibilities. These include the description 
of interactive programmes (such as live coverage of sports events with multiple user-selectable streams), games and 
educational packages (where documents, applications and other digital content may accompany the main audiovisual 
content and where the student may wish to control the choice and sequence of resources put to use). Here too, these 
capabilities may be combined with targeting tools (e.g. to enable account to be taken of the personal characteristics and 
usage environments of users). 

The new user description tools are the mirror image of those required for content targeting. They may also serve as a 
basis for content sharing between users (and between usage environments). 

6.3.3.2 Phase 2 as an extension to Phase 1 metadata tools 

It is important to note that the Phase 2 extensions to the Phase 1 metadata tools are, like their predecessor, modular. 
They constitute additions to the TV-Anytime metadata toolbox. There is no need, therefore, for Phase 1 implementations 
to evolve in one leap to comprehensive Phase 2 compliance. A precedent for this exists in the MPEG-7 practice of sub 
setting schema tools through the use of profiles and of levels within profiles. 

There are many options for step-by-step rollout of Phase 2 metadata tools. The tools can be grouped into three broad 
areas of functionality that they support: 

1) Extended content description (largely the responsibility of content creators and metadata service providers, but 
also with implications for developers of metadata-using client software) 

2) Extended user description (largely the domain of equipment manufacturers and application software 
developers) 

3) Content package description, including support for interstitials. This presents a complex challenge (with 
commensurate potential rewards), analogous to that posed by segmentation in Phase 1 and will require 
co-ordinated action by all members of the value chain. 

Although the three areas are to some degree interdependent, areas one and two could be partially or completely 
implemented before area three. Tools for the description of new non-AV content types, context-specific content 
characteristics, RMPI and coupons could initially be partially or completely deployed. 

At the stage of complete deployment of these extended content description tools, deployment of the extended user 
description tools would be necessary (to fully enable content and coupon targeting). 

Once these tools are in place, but only then, tools for content packaging (including interstitials) can be deployed. It 
would not be possible to deploy the latter effectively without the prior deployment of tools for extended content 
description (needed, e.g., to describe components of packages), and for extended user description (needed, e.g., to 
ensure that package components are matchable to usage environment characteristics). 
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6.4 Documents related through the GRID 

Parts of a TV-Anytime document are related through the CRID. Metadata may be distributed across many TV-Anytime 
documents, but it is always possible to relate appropriate pieces through CRIDs. 

6.4.1 Grouping 

Programmes can belong to groups, and groups can belong to other groups. Linking programme descriptions with group 
descriptions using CRIDs reflects this relationship in the metadata, again, which is illustrated in figure 8. 
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Figure 8: Programme descriptions related to group descriptions through the CRID 

Programlnformation elements are related to Grouplnformation elements through the memberOf or episodeOf elements, 
e.g. the memberOf element contains a group CRID e.g. Foxes Episode 11 is a member of the Foxes group, which is a 
group that aggregates all episodes of Foxes. This supports the feature where a viewer can say "I like this. What is it? 
Are there more programmes like this?" By navigating up to the group the viewer may discover that the group is a 
member of another group and so forth. The higher one goes in the tree the more general the concepts become, 
e.g. moving from a specific episode of Foxes, to all episodes of Foxes, to all comedy shows, to all shows. 

This upward pointing nature of group representation in the TV-Anytime metadata is the opposite of the content 
resolution process which is downward pointing (group CRIDs resolve into other CRIDs which resolve into locators). 

6.5 TV-Anytime document structure 

The following example illustrates the structure of a valid TV-Anytime document: 

<TVAMain xmlns="urn:tva: metadata: 2 005" 

xmlns :mpeg7="urn : tva :mpeg7 : schema : 2005" 

xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 

xsi : schemaLocation="urn : tva : metadata : 2 005 schemas/tva_metadata_3-l_vl31 . xsd" 

version="03" 

xml : lang="en" 

publisher=" ..." 

publicationTime="2 001-04-05121:00: 00. 00 + 01: 00 "> 

<CopYrightNotice> . . . </CopyrightNotice> 

<ProgramDescription> 

<ProgramInf ormationTable> . . . </Programlnf ormationTable> 

<Grouplnf ormationTable> . . . </Grouplnf ormationTable> 

<ProgramLocationTable> . . . </ProgramLocationTable> 

<ServiceInf ormationTable> . . . </Servicelnf ormationTable> 

<CreditsInf ormationTable> . . . </CreditsInformationTable> 

<ProgramReviewTable> . . . </ProgramReviewTable> 

<PurchaseInf ormationTable>. ..< /Purchase InformationTable> 

</ProgramDescription> 

<UserDescription> 

<UserPref erences> . . . </UserPreferences> 
<UsageHistorY> . . . </UsageHistory> 

</UserDescription> 
</TVAMain> 
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Many of the elements are optional, so the following examples are also valid documents: 

<TVAMain version="03" xml : lang="en" publisher=" . . " publicationTime=" . . "> 

<CopyrightNotice> . . . </CopyrightNotice> 

<ProgramDescription> 
<ProgramInf ormationTable> . . . </ProgramInf ormationTable> 

</ProgramDescription> 
</TVAMain> 



<TVAMain version="03" xml : lang="en" publisher=" . . " publicationTime= 

<CopyrightNotice> . . . </CopyrightNotice> 

<ProgramDescription> 
<GroupIn format ionTable></GroupInformationTable> 

</ProgramDescription> 
</TVAMain> 



<TVAMain version="03" xml : lang="en" publisher=" . . " publicationTime= 
<Copy r i ght Not i ce >...</ Copy right No tice> 
<UserDescription> 
<UserPreferences>...</UserPreferences> 
<UsageHistory>...</UsageHistory> 
</UserDescription> 
</TVAMain> 



6.6 Mandatory and optional elements 

The TV-Anytime XML Schema contains many elements that are optional and some that are mandatory. The diagram 
shows the mandatory parts of Programlnformation: 

<P rogramin format ionTable> 
<ProgramInf ormation programId="crid: //hbc . com/f oxes/ episode 1 "> 
<BasicDescription> 
<Title type="main"> 

The one where Fox jumps in the Potomac 
</Title> 
</BasicDescription> 
< /P rogramin format ion> 
</ProgramInf ormationTable> 



6.7 Delivery of metadata over a unidirectional environment 

The TV-Anytime forum has specified a generic solution for the carriage of metadata over unidirectional environments. 
Unidirectional environments are defined as being environments where content and metadata are delivered from the 
transmitting device (head-end) to the terminal device (PDR) over a one-way link and where no communication is 
possible from the PDR to the head-end. The TV-Anytime solution is not specific to a particular transport layer and has 
been designed so as to be used within any unidirectional delivery system. The requirements needed to be fulfilled by 
such a system in order to be able to implement this solution are listed in annex B. 

The TV-Anytime solution has been designed to support the following methods of acquisition of the TV-Anytime 
metadata sent out over a unidirectional network: 



• 



Method 1 : Acquire from the metadata stream and cache the data to disk with the receiver provides its own 
methods of navigation. 

Method 2: Use the TVA indexing solution to enable online navigation of the metadata stream. 

Method 3: Cache both TVA indexing information and data to disk to provide an enhanced version of 
method 2. 
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Accordingly the delivery of a TV-Anytime description, namely the actual document containing all the TV-Anytime 
metadata from a certain metadata provider to be sent out at a certain time, is viewed as made of five distinct processes. 
Figure 9 shows the processes associated with the delivery of metadata. Those specified by the TV-Anytime delivery 
solution are shown in grey. 
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Figure 9: Processes associated with the delivery of metadata 

Fragmentation is the generic decomposition mechanism of a TVA metadata description into self-consistent units of 
data, called TVA fragments. A fragment is the ultimate atomic part of a TV-Anytime metadata description that can be 
transmitted independently to a terminal. A fragment shall be self consistent in the sense that: 

• It shall be capable of being updated independently from other fragments. 

• The way it is decoded, processed and accessed shall be independent from the order in which it is transmitted 
relative to other fragments. 

• The decoding of a fragment and its addition to the partial description shall give a TV-Anytime schema valid 
description. Note that a partial description must have at least the fragment delivering the root element 

(TVAMain). 

A number of normative TVA fragment types have been defined as follows: 

TVAMain fragment which contains the root element of the description. 

Programlnformation fragment containing metadata for a given content. 

Grouplnformation fragment containing metadata for a given group of contents. 

OnDemandProgram and OnDemandService fragment for the description of on-demand instances of contents. 

BroadcastEvent fragment. Schedule fragment and Servicelnformation fragment used for the description of 
broadcast instances of contents and of the services where they are available. 

For the Creditlnformation metadata, PersonName and OrganizationName fragments. 

Review fragment to contain review of a given content. 

Purchase Information fragment to contain price information. 

For the ClassificationSchemes metadata, CSAlias fragment and Class if icationScheme fragment. 

For the Segmentation metadata, Segmentlnformation fragment and SegmentGroupInformation fragment. 

Encoding is the process that enables the efficient (in terms of bandwidth, navigability and updating) delivery of data 
within a unidirectional environment. It consists in representing the TVA metadata fragments in a binary format. 
TV-Anytime has chosen the MPEG-7 BIM method as defined in ISO/IEC 15938-1 [15] (MPEG-7 Systems part) as the 
preferred method that would facilitate wide interoperability. However TV-Anytime appreciates that in some controlled 
environments, it may be desirable to enable the delivery of metadata using alternate encoding systems. To allow this, 
appropriate hooks are provided where necessary and the means to indicate the method of encoding used. 

Encapsulation is the process, which enable the grouping of a number of binarised fragments together in a "container" 
ready for transmission. It associates to these fragments further information enabling a receiving device to manage them. 
In particular it allocates to each fragment a unique identifier within the TVA metadata fragment stream and a version 
number so as to enable the monitoring of possible updates. 
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To conclude, indexing is the optional mechanism seen as suiting especially situations when TVA metadata is to be 
delivered to receivers that have limited processing and storage capabilities. As within a TV-Anytime metadata fragment 
stream there is are likely to be many hundreds of fragments, indexing provides a mechanism for locating information 
from within this stream. It allows multiple views on the data set of a TVA metadata description and enables a device to 
quickly find a fragment of interest. Indexing structures sent out along with the TVA metadata fragment stream provide 
direct access to each TVA fragment by listing the values of a particular node (the index's key fields) and describing 
where the matching fragment(s) can be found over the delivery layer. Multiple indices can point to the same fragment, 
each using a different node as a key field. The indexing structures when provided are transmitted using the generic 
container format defined by the encapsulation mechanism. 

For the transmission, TV-Anytime does not define the way in which these containers should be carried, as this is specific 
to the delivery system. However in the specification of a container, consideration has been given, to enable the 
container to be easily mapped on to standard delivery methods. For example in an MPEG-2 environment, the containers 
may be conveyed using Sections, objects within a DSM-CC U-U Object Carousel or modules within a DSM-CC Data 
Carousel. 

6.8 Notes on Schema Extension 

The TV-Anytime Schema defined in TS 102 822-3-1 [2], provides a standard way of describing common data structures 
required within a PDR environment. However there may be instances where third parties may wish to extend the TVA 
Schema to provide enhancements to existing data types, or to introduce completely new data types, providing additional 
functionality. 

This can be achieved in a backward compatible way using standard XML Schema methods. TS 102 822-3-2 [3] defines 
a subset of these XML Schema methods which are applicable within the context of a TVA Schema. 

Note that the declaration of new data types must occur in a separate schema document and have their own unique 
namespace. 

6.8.1 Polymorphism of existing type by inheritance with extension 

To extend an existing TVA data type one uses the XML Schema, derive by extension mechanism. So for example if a 
provider wish to add a new element called MyData to a standard TVA ProgramlnformationType, he would define a new 
type as follows: 

<xs : schema xmlns : xs = "http : //www . w3 . org/2 001 /XMLSchema" xmlns : tva="urn : tva : metadata : 2 005 " 
elementFormDefault=" qualified" attributeFormDef ault=" ungual if led" > 

<xs : import name space=" urn : tva : metadata : 2 005 " schemaLocation="tva_metadata_3- 
l_vl31.xsd"/> 

<xs : complexType name="MyDataType"> 
<xs : complexContent> 

<xs : extension base="tva : Programinf ormationType"> 
<xs : sequence> 

<xs: element name="MyData" type="xs : string" /> 
</xs : sequence> 
</xs:extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : schema> 

To use the new data type within an instance document, one makes use of the XML Schema "type" attribute to declare 
the actual data type as follows: 

<tva:TVAMain xmlns : tva="urn : tva : metadata: 2 005" 
xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 
xsi : noNamespaceSchemaLocation="ExampleTvaExtension . xsd"> 
<tva : ProgramDescription> 

<tva : Programinf ormationTable> 

<tva : Programinf ormat ion p r ogr ami d=" GRID : //bbc . com/fi 1ms /titanic" 
xsi :type="MyDataType"> 
<tva : BasicDescription> 

<tva:Title>Titanic</tva:Title> 
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</tva : Bas i cDe script! on > 
<MyData>xxxxxxxxx</MyData> 
</tva : Programinf ormation> 
</tva : Programinf ormationTable> 
</tva : ProgramDescription> 
</tva:TVAMain> 



If no "type" is declared for the extended type the system assumes that it is of the base type, which in this case is 
ProgramlnformationType. 

It should be noted that all new data elements occur at the end of the extended data type. In the case where an extension 
adds new attributes, then these attributes can occur in any order within the extended element. 

6.8.2 Polymorphism of existing type by inineritance witin restriction 

To restrict an existing TVA data type one uses the XML Schema, derive by restriction mechanism. So for example if a 
provider wishes to create a new data type called MyDataType which removes all optional elements from the standard 
TVA ProgramlnformationType, he would define a new type as follows: 

<xs : schema xmlns : xs = "http : //www . w3 . org/2 001 /XMLSchema" xmlns : tva="urn : tva : metadata : 2 005 " 
elementFormDefault=" qualified" attributeFormDef ault="unqualif ied"> 

<xs : import name space=" urn : tva : metadata : 2 005" 
schemaLocation=" . /tva_metadata_vl3 . xsd_aml " /> 
<xs : complexType name="MYDataType"> 
<xs : complexContent> 

<xs: restriction base="tva : Programinf ormationType"> 
<xs : sequence> 

<xs : element name="BasicDe script ion" type="tva : BasicContentDescriptionType" /> 
</xs : sequence> 

<xs : attribute name="programId" type="tva : CRIDType" use="required"/> 
<xs : at tribute Group ref ="tva : fragment Identification " /> 
</xs:restriction> 
</xs : complexContent> 
</xs : complexType> 
</xs : schema> 

To use the new data type within an instance document, one makes use of the xsi:type attribute to declare the actual data 
type as follows: 

<tva:TVAMain xmlns :tva="urn : tva : metadata : 2 005" 
xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 
xsi : noNamespaceSchemaLocation="ExampleTvaExtension . xsd"> 
<tva : ProgramDescription> 

<tva : Programinf ormationTable> 

<tva : Programinf ormat ion p r ogr ami d=" GRID : //bbc . com/fi 1ms/ titanic" 
xsi :tYpe="MyDataTYpe"> 
<tva : BasicDescription> 

<tva:Title>Titanic</tva:Title> 
</tva : BasicDescription> 
</tva : Programinf ormat ion> 
</tva : Programinf ormat ionTable> 
</tva : ProgramDescription> 
</tva:TVAMain> 

If no "type" is declared the system assumes that it is of the base type, which in this case is ProgramlnformationType. 
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7 



Phase 1 cookbook examples and scenarios 



This clause describes the phases identified in a TV-Anytime System. It is followed by examples to give an overview of 
how a system might work. Further details and issues that arise from this example are identified in the next clause. The 
examples will cover usage of both content referencing and metadata (including the usage of metadata over a 
bi-directional link). 



7.1 r\/-/AA?yf//77e dynamic processes 

Processes in a TV-Anytime session are depicted in figure 10. 




Figure 10: Processes in a 7l/->*nyf/me system 

The next clauses present an examples that show, per process, the steps that are to be taken in a TV-Anytime system. 

7.2 Phase 1 example: Record every episode of this programme 
series in the broadcast case 

This example shows how the current TV-Anytime system may work using the TS 102 822-4 [6], TS 102 822-3-1 [2] and 
TS 102 822-3-2 [3]. The example is intended to give an overview of the system; more specific issues per phase will be 
covered later in this document. 

Publish 

A content creator will publish a CRID that represents a programme series, and CRIDs that represent the constituents of 
that programme series. The same or different service provider will publish metadata that describes this series and its 
constituent episodes. The same or different service provider will publish location resolution data that describes where 
and when the constituent episodes of this series may be acquired. The series may be available from multiple content 
creators. 

In this example we will use a comedy show "Fox" which has two episodes. The included XML snippets show an almost 
minimal way to describe this show and its episodes. Three metadata tables are needed to describe the relations for the 
Fox show. The Grouplnformation table that holds information for all episodes of Fox and two Programlnformation 
tables that contain information for the different episodes. 

The link between the group and the episodes is made by the content referencing system: if the Group CRID 
"//hbc/foxes/all" is put to the resolution engine in the FDR, it will come back with both programme CRIDs. The link 
between programmes and the group is being made by the <memberOf> element in the Programlnformation table. 

<ProgramDescription> 

<P rogramin format ionTable> 

<ProgramIn format ion programId="crid: //hbc . com/f oxes/episodel"> 
<BasicDescription> 

<Title type="main"> 

The one where Fox jumps in the Potomac 
</Title> 

<SYnopsis length=" short "> 

Fox goes to Washington and jumps in the Potomac 
</Synopsis> 
</BasicDescription> 
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<MemberOf xsi : type="EpisodeOf Type" crid="crid: //hbc . com/foxes/all" /> 
</ProgramInf ormation> 

<ProgramIn format ion programId="crid : //hbc . com/foxes/ episode 2 "> 
<BasicDescription> 

<Title tYpe="main"> 

The one where Fox drowns in the Lake of Geneva 
</Title> 

<Synopsis length="short "> 

Fox goes to Geneva and tries to climb the fountain 
</Synopsis> 
</BasicDescription> 

<MemberOf xsi : type="EpisodeOf Type" crid="crid: //hbc . com/f oxes/all" /> 
</ProgramInf ormation> 
</ProgramInf ormationTable> 
<GroupIn format ionTable> 

<GroupInf ormation groupId="crid : //hbc . com/f oxes/all" ordered="true" numOf Items="2 "> 
<GroupType xsi : type="ProgramGroupTypeType" value="show"/> 
<BasicDescription> 

<Title type="main"> 
All episodes of Foxes ever 
</Title> 

<Synopsis length=" short "> 
More Foxes than you can handle 
</Synopsis> 
</BasicDescription> 

<MemberOf xsi : type= "Member Of Type" crid="crid: //hbc . com/ comedy /all" /> 
</GroupInf ormation> 
</GroupInf ormationTable> 
</ProgramDescription> 

To allow PDRs to build for, example, an EPG or to inform the user of the approximate schedule of an airing, 
InstanceMetadata can be used. This is useful, for example, when a user is interested in watching a programme in a 
non-time shifted manner. The BroadcastEvent table in the instance metadata is used for that purpose. It is NOT there to 
signal to the PDR where and when a particular programme really can be found: that is the job of content referencing and 
location resolution mechanism. As stated before, the metadata is used mainly for attraction purposes. An example XML 
snippet of a BroadcastEvent table is given below: 

<ProgramLocationTable> 

<BroadcastEvent servicelDRef = "hbcl00022311"> 

<Program crid="crid: //hbc . com/f oxes/ episode 1 " /> 
<BroadcastURL>dvb: //I . 4ee2 . 3f 4/</BroadcastURL> 

<EventDescription> 
<PublishedTime>2 001-04-05T2 1:00: 00. 00+0 l:00</PublishedTime> 
<PublishedDuration>PT3H</PublishedDuration> 

</EventDescription> 

</BroadcastEvent> 
</ProgramLocationTable> 



Search 

One example of a search is a user searching for the title of a series, e.g. "Foxes", that he is interested in. The result of 
the search is a list of matching titles and associated identifiers (CRIDs). To refine his search further, the user must 
examine other metadata that can be attached to the GRID. The user can refine his search further to identify the particular 
series he wants to acquire, e.g. "Foxes in the Wild". The search may then be refined even further, e.g. by specifying 
PPV or free-to-air or quality. 

Another example is that a user likes the programme he is currently viewing and wants to see more programmes like this 
one. First the system must find the GRID of the current programme being viewed. If the programme is played from disk 
then the system should have stored the identity of the programme and associated metadata. If the programme is "live" 
then the system must be able to find the GRID of the programme on the current channel. Once the GRID has been found 
then the system must find the metadata associated with this GRID and interrogate it. In this example the programme is a 
member of a series. The user reads the description of the series and decides to record the whole series. 
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Other search mechanisms, based on the UserPreferences metadata are also possible. The search intention can for 
example be captured in the UserPreference DS. 

In this example the user searches for "Fox". The PDR in this example examines the title and synopsis fields of the 
Group and Program Information table and outputs as a result of his search three descriptions, one of the group, and two 
of the episodes. Other implementations could also search other metadata elements like keywords or genre. The user 
selects episode 2 and reads the synopsis. For this example we assume that after viewing info about this episode the user 
wants to record the whole series. 

Select 

For our example we assume that the PDR will offer the user the option to record the whole series. At this point to get 
the whole series the PDR examines the MemberOf element in the Programlnformation table and sees that the episode is 
part of a show called "Fox" with GRID "//hbc.com/foxes/all". With this GRID available it will try to locate the actual 
episodes in the next phase. 

At this point the usage history metadata table in the PDR could be updated, showing that the user has made a selection. 
An example XML snippet is below: 

<UserDescription> 

<UsageHistorY i d=" usage -history-OOl" allowCollection="true"> 
<mpeg7 :UserIdentif ier protected="true"> 

<mpeg7:Name xml : lang="en">John Doe</mpeg7 :Name> 
</mpeg7 :UserIdentif ier> 

<mpeg7 :UserActionHistory id="useraction-history-001" 
protect ed="false"> 
<mpeg7 :ObservationPeriod> 

<mpeg7 : TimePoint>2 001-02-02T18 : 00-08 : 00</mpeg7 :TimePoint> 
<mpeg7 :Duration>PT96H</mpeg7 :Duration> 
</mpeg7 : ObservationPeriod> 
<mpeg7 :ObservationPeriod> 

<mpeg7 : TimePoint>2 001-02-02T18 : 00-08 :00</mpeg7 :TimePoint> 
<mpeg7 :Duration>PT6H</mpeg7 :Duration> 
</mpeg7 : ObservationPeriod> 

<mpeg7 : UserActionList id="ua-list-001" numOf Instances="l" 
totalDuration="PT2H30M"> 

<mpeg7 : ActionType href =" urn : tva : metadata : cs : ActionTypeCS :2004:1.3"> 

<mpeg7 :Name>Record</mpeg7 :Name> 
</mpeg7 :ActionType> 
<mpeg7 :UserAction> 
<mpeg7 : ActionTime> 
<mpeg7 :MediaTime> 

<mpeg7 :MediaTimePoint>2 001-02-02T19 : 00 : 00</mpeg7 :MediaTimePoint> 
<mpeg7 :MediaDuration>PTlH</mpeg7 :MediaDuration> 
</mpeg7 :MediaTime> 
</mpeg7 :ActionTime> 

<mpeg7 : Programldentif ier organization="TVAF" 

type="CRID">crid : //hbc . com/f oxes/all</mpeg7 : Programldentif ier > 
</mpeg7 : UserAction> 
</mpeg7 :UserActionList> 
</mpeg7 :UserActionHistory> 
</UsageHistory> 
</UserDescription> 

This usage history could also be used by the PDR to fill the user preference metadata tables. A more extensive example 
of usage history can be found in annex A. 

As far as the user is concerned, the system will now autonomously make the content available at some point in the 
future. 

Locate 

Once the particular series has been chosen the series must be "resolved" to its constituent episodes. Given the GRID for 
the series the location resolution functional unit will return a list of GRIDs that refer to each episode. This relies on the 
fact that the location resolution data is made available to the box. 
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The resolution process continues until each of the episodes is then resolved to locations (channel/time/duration in the 
broadcast case). For each episode there may be several locations, e.g. repeats. These locations contain the same content 
as far as the service provider is concerned. 

For our example, the show "Fox" has the following resolution tables associated with it: 

<ContentRef erencingTable> 
<! — GRID resolution to other CRIDs — > 
<Result CRID="crid: //hbc . com/ foxes /all" 

status="resolved" complete="true" acquire="all"> 
<CRIDResult> 
<Crid>crid: //hbc . com/ foxes /episode 1</Crid> 
<Crid>crid: //hbc . com/f oxes/episode2</Crid> 
</CRIDResult> 
</Result> 

< ! -- GRID resolution to locators --> 

<Result CRID="crid : //hbc . com/f oxes/ episode 1 " status=" resolved" 
complete="true" acquire="all"> 
<LocationsResult> 
<Locator>dvb://1.4ee2.3f4;4f5@2001-04-05T21:00:00.00+01:00/PT00H45M 
</Locator> 
</LocationsResult> 
</Result> 

<Result CRID="crid : //hbc . com/f oxes /episode 2 " 
status="cannot yet resolve" complete="true" 

acquire="all" reresolveDate = "2001-09-09T12 : 00 : 00 . 00+01 : 00"> 
</Result> 
</ContentRef erencingTable> 

In the XML instance it can be seen that the Group GRID has two GRIDs associated with it, those of episode 1 and 2 of 
"Fox". In the example a DVB locator is used for episode one, the PDR already knows when and where this episode can 
be found. Episode two is somewhere in the future at an unknown time, so if the PDR tries to resolve that it will know to 
try again after the 9* of September 2001 . 

Note that the syntax of the locator is not specified here. For purposes of illustration, a locator has been dreamt up by 
appending an existing DVB locator with an "@" and a string to express time and duration according to ISO 8601 [16]. 

Acquire 

The local storage management function will use any alternative locators to resolve recording conflicts. The chosen 
locator will then be used to tune to the specified channel at the specified time and record for the specified duration. To 
ensure that the content is recorded the system must monitor for changes in the location of the content. For example, the 
programme may be moved to a different channel. This may involve re-resolution of the GRID. 

In addition, to accurately record the desired content it may be necessary to take advantage of lower-level system 
features such as Programme Delivery Gontrol (PDG) or DVB event IDs. An example would be where the showing of a 
programme is delayed - if the original time and duration are followed the end of the programme will not be recorded. 

Verification that actually the programme that was asked for has been recorded is not currently supported in TV- Anytime . 

View 

Once the episodes of the series have been acquired they are made available for viewing. As the viewer may want to 
view the associated metadata at the time of playback, the system should store the associated metadata at the time of 
selection or capture. If the metadata changes between selection and playback, it may be necessary to use version or 
timestamp information to present useful information to the user. For example, if one episode of a series advertised a 
particular guest actor as appearing, but did not take part, this may affect whether the user may wish to view the 
programme. 

To allow users to know what they actually have recorded on their PDR, at least a minimal set of metadata needs to be 
kept with the content. In our example that could be Programlnformation tables, allowing the user to see title and 
synopsis of programmes he recorded. 
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Finish 

This may involve a user preference system storing information about the viewing of this series or episode. This 
information could then be used by an agent to determine the preferences of the user. An extensive example of usage 
history can be found in annex A. 

The following figure gives a graphic representation of this process. 
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Figure 11: Dynamic behaviour of 7l/^->*nyf;me system example 

7.3 Phase 1 example: Record highlights from a football match 
via an EPG 

There are two ways to achieve this functionality. If the original match and the highlights are separate pieces of content 
identified by different CRIDs, the highlights can be captured by using the appropriate CRID. The alternative, described 
below, uses segmentation metadata. 

Publish 

A content creator will publish a CRID that represents the football programme. The same or different service provider 
will publish content metadata that describes this programme. The same or different service provider will publish 
segmentation metadata that describes the highlights of this programme. The same or different service provider will 
publish location resolution data that describes where and when this programme may be acquired. The programme may 
be available from multiple content creators. 
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Figure 12: Highlight segmentation 

The following XML snippet shows a minimal way to describe the program information and program location metadata 
for the football programme. 

<ProgramDescription> 

<P rogramin format ionTable> 

<ProgramIn format ion programId="crid : //sport . com/f ootball/matchlO"> 
<BasicDescription> 

<Title tYpe="main">Ireland Vs Saudi Arabia</Title> 
<SYnopsis length="short "> 

Ireland qualifies for the second round of the world cup 
</Synopsis> 
</BasicDescription> 
</ProgramInf ormation> 
</ProgramInf ormationTable> 
<ProgramLocationTable> 

<BroadcastEvent service IDRef="hbcl 0022 311 "> 

<Program crid="crid: //sport . com/f ootball/matchlO" /> 
<ProgramURL>dvb: //I . 4ee2 . 3f 4/</ProgramURL> 

<PublishedStartTime>2 002-0 6-05T18 :00:00. 00+01: 00</PublishedStartTime> 
<PublishedDuration>PT6H</PublishedDuration> 
< /Broadcast Event > 
</ProgramLocationTable> 
</ProgramDescription> 

The segmentation metadata may be broadcast separately from the programme and it is associated programme 
information/programme location metadata. Segment metadata is "overlaid" on the original content. This means that the 
original content is published and various different segmentation schemes can be applied to it, for example, highlights 
with different durations. The following XML shows the segmentation metadata for the highlights. 

The segment group is of type "Highlights/Events". It references the CRID of the football programme and contains 
references to three segments. The three highlight segments and the segment group are described as follows: 
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<ProgramDescription> 
<SegmentInf ormationTable> 
<SegmentList> 
<Segment Information segment Id="S2 7A67 7 5 8-E7 14 -4a4e-B9 94- 
3B650A443699"> 

<ProgramRef crid="crid: //sport. com/foot ball /match 10 " /> 
<Description> 

<Title xml:lang="en">Highlight 1</Title> 
<Synopsis xml : lang="en">The first goal</Synopsis> 
</Description> 
<SegmentLocator> 
<MediaRe liner TimePoint 

mediaTimeUnit="PTlN25F">102 91 
</MediaRelIncr TimePoint > 
< MedialncrDuration 

mediaTimeUnit="PTlN25F">154 70 
< /Media IncrDur at ion> 
</ Segment Locat or > 
< /Segment I nformation> 

<Segment Information segment Id=" 304 6C7C0F-BF83-4b4d-9 69E- 
204E8E82CF7C"> 
<ProgramRef crid="crid : //sport . com/f ootball/matchlO" /> 
<Description> 
<Title xml:lang="en">Highlight 2</Title> 
Oynopsis xml : lang="en">The second goal</Synopsis> 
</Description> 
<Segment Locat or > 

<MediaRel I ncr TimePoint mediaTimeUnit="PTlN2 5F"> 

22291 
</MediaRe liner TimePoint> 

< MedialncrDuration mediaTimeUnit="PTlN25F"> 
26470 
</ MediaIncrDuration> 
</ Segment Locat or > 
< /Segment I nformation> 

<Segment Information segment Id="S51 17353A-F5 98-4del-9 68E- 
8C3D134C7642"> 
<ProgramRef crid="crid: //sport . com/f ootball/matchlO" /> 
<Description> 

<Title xml:lang="en">Highlight 3</Title> 
<Synopsis xml : lang="en">The third goal</Synopsis> 
</Description> 
< Segment Locat or > 
<MediaRe liner TimePoint mediaTimeUnit="PTlN2 5F"> 

39291 
</MediaRel I ncr TimePoint > 
<Media IncrDur at ion mediaTimeUnit="PTlN2 5F"> 

55470 
< /Media IncrDur at ion> 
</ Segment Locat or > 
< /Segment In formation> 
</ Segment List > 
<SegmentGroupList> 

<SegmentGroupInformation groupId="G92F0C7 07-2ECB-4 03a-8 8FC- 
89EEF7961034"> 

<ProgramRef crid="crid: //sport. com/f ootball/matchlO " /> 
<GroupType xsi : type=" Segment GroupTypeType" 

value="highlights /events" /> 
<Description> 
<Title xml : lang="en">Match Highlights</Title> 
<Synopsis xml : lang="en">Goals from the match</Synopsis> 
</Description> 

<Segments ref List="S27A677 5 8-E714-4a4e-B994-3B650A4 43 6 99 
S04 6C7C0F-BF83-4b4d-9 69E-204E8E82CF7C 
S5117353A-F5 98-4del-9 68E-8C3D134C7 642"/> 
< /Segment Group I nformation> 
</SegmentGroupList> 
</ Segment InformationTable> 
</ProgramDescription> 
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Search 

The PDR will use the information from the Programlnformation and ProgramLocation tables to render an EPG. The 
ProgramLocation table is used by the PDR to know the expected time and channel where the programmes will be 
shown, and the Programlnformation table is used to provide the location-independent information about each 
programme (such as title and synopsis). 

The user can then navigate around this EPG to find content that they wish to acquire. 

Select 

For our example we assume that the PDR will offer the user the option to view either the original football programme or 
the highlights of that programme via the EPG. The user wishes to watch the highlights and selects this option from the 
EPG. 

EPG for channel XX 

6pm - 8pm Football: Ireland Vs Saudi Arabia I Highlights 



As discussed in the View section the fact that the user has selected the highlights does not affect the actual content 
acquired. It simply indicates that the highlights segment metadata should also be acquired at some time and applied to 
the content when it is viewed. 

At this point the usage history metadata table in the PDR could be updated, showing that the user has made a selection. 
An example XML snippet is shown in the first cookbook scenario. 

This usage history could also be used by the PDR to fill the user preference metadata tables. As far as the user is 
concerned, the system will now autonomously make the content available at some point in the future. 

Locate 

Once the particular football programme has been chosen the programme GRID must be "resolved" to a unique locator 
(channel/time/duration in the broadcast case). This relies on the fact that the location resolution data is made available 
to the PDR. For this football programme there may be several locations, e.g. repeats. These locations contain the same 
content as far as the service provider is concerned. 

For our example, the football programme has the following simple resolution tables associated with it: 

<ContentRef erencingTable> 
< ! -- GRID resolution to locators --> 
<Result CRID="crid: //sport . com/f ootball/matchlO" 
status="resolved" complete="true" acquire="all"> 
<LocationsResult> 
<Locator>dvb: //I . 4ee2 . 3 f4; 4 £502001-04- 

05T2 1:00: 00. 00+01 :00/PT00H45M 
</Locator> 
</LocationsResult> 
</Result> 
</GontentReferencingTable> 

In the XML instance it can be seen that the football programme has only one locator associated with its GRID. In the 
example a DVB locator is used. The PDR already knows when and where this episode can be found. Note that the 
syntax of the locator is not specified here. For purposes of illustration, a locator has been created by appending an 
existing DVB locator with an "@" and a string to express time and duration according to ISO 8601 [16]. 

Acquire 

The locator will be used to tune to the specified channel at the specified time and record for the specified duration. To 
ensure that the content is recorded the system must monitor for changes in the location of the content. For example, the 
programme may be moved to a different channel. This may involve re-resolution of the GRID. 
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The segmentation metadata may be acquired at the same time as the content or it may be intermittently broadcast from 
the carousel and acquisition may occur at a later time. 

There is also the possibility that the segmentation metadata could be updated over time. If the metadata changes 
between selection and playback it may be necessary to use version or timestamp information to present useful 
information to the user. For example, the highlights may be changed if one of the players in the match is later named as 
the best player of the tournament. 

View 

Once the football programme has been acquired they are made available for viewing. The user has captured the original 
football programme plus the segment metadata that applies to that programme. As the user chose the view the highlights 
from the EPG this is the version that should be displayed when the user views the programme. Of course as the original 
content has been captured an option can be provided to view the full programme as well. 

How this preference (full content/highlights) is stored on the box is an implementation issue. It may be as simple as a 
flag attached to the content indicating whether the associated segment metadata is to be utilized. 

As the user has selected the highlights, the following events occur when the programme is viewed: 

• The SegmentGroupinf ormation is processed by the PDR. There are three segments associated with the 
CRID crid: //sport. com/football/match 10. 

• Each individual Segmentinf ormation is processed and the segmentLocator is used to index a particular 
segment of the referenced CRID. 

• The segments are played. The PDR will play the highlights in a continuous ordered manner. Interstitial content 
such as title screens/advertising shall be part of the original programmes and identified as highlights/events. 

To allow users to know what they actually have recorded on their PDR, at least a minimal set of metadata needs to be 
kept with the content. In our example this metadata could be the Programlnformation tables, allowing the user to see the 
title and synopsis of programmes that have been recorded. 

Finish 

This may involve a user preference system storing information about the viewing of this programme. An agent to 
determine the preferences of the user could then use this information. For example from this and other recordings it may 
be obvious that the user always views the highlights of sporting events and never the entire content. 

7.4 Phase 1 example: Select a particular showing of a 
programme from an EPG (in the broadcast case) 

Publisli 

A content creator will publish CRIDs for each programme in its schedule. They will also publish programme 
description and programme location metadata for these programmes. The same or different service provider will publish 
location resolution data that describes where and when the programmes from the schedule may be acquired. 

The included XML snippets show an almost minimal way to describe this schedule. Two metadata tables are needed to 
describe the schedule. The Programlnformation table contains information for each of the different programmes. The 
ProgramLocation table contains the time and channel information necessary to render an EPG. The link between the 
time and channel information for a programme and its location-independent description is made by the CRID. It is 
worth noting that the ProgramLocation table is NOT there to signal to the PDR where and when a particular programme 
really can be found: that is the job of content referencing and location resolution mechanism. 
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<ProgramDescription> 

<ProgramInf ormationTable> 

<ProgramIn format ion programId="crid : //hbc . com/f oxes/ episode 1 "> 
<BasicDescription> 

<Title tYpe="main"> 

The one where Fox jumps in the Potomac 
</Title> 
<SYnopsis length="short "> 

Fox goes to Washington and jumps in the Potomac 
</Synopsis> 
</BasicDescription> 
</ProgramInf ormation> 

<ProgramInf ormation programId="crid: //hbc . com/ news /six"> 
<BasicDescription> 

<Title tYpe="main"> 

The HBC 6 o'clock News 
</Title> 
<Synopsis length="short "> 

The latest news and sports from around the world 
</Synopsis> 
</BasicDescription> 
</ProgramInf ormation> 

<ProgramIn format ion programId="crid: //hbc . com/ bear/ woods "> 
<BasicDescription> 

<Title type="main"> 

The Bear Show in the Woods 
</Title> 
<Synopsis length=" short "> 

Bear sings a medley of songs from One Hundred Tree Wood 
</Synopsis> 
</BasicDescription> 
</ProgramInf ormation > 
< /Programin format ionTable> 
<ProgramLocationTable> 

<BroadcastEvent servicelDRef = "hbcl00022311"> 
<Program crid="crid : //hbc . com/news/ six" /> 
<ProgramURL>dvb: //I . 4ee2 . 3f 4/</ProgramURL> 

<PublishedStartTime>2002-06-05T18 : 00 : 00 . 00+01 : 00</PublishedStartTime> 
<PublishedDuration>PT30H</PublishedDuration> 
< /Broadcast Event > 
<BroadcastEvent servicelDRef = "hbcl00022311"> 

<Program crid="crid: //hbc . com/f oxes /episode 1 " /> 
<ProgramURL>dvb: //I . 4ee2 . 3f 4/</ProgramURL> 
<InstanceMetadataId>imi : f ell</InstanceMetadataId> 

<PublishedStartTime>2002-06-05T18 : 30 : 00 . 00+01 : 00</PublishedStartTime> 
<PublishedDuration>PT30H</PublishedDuration> 
< /Broadcast Event > 

<BroadcastEvent servicelDRef = "hbcl00022311"> 
<Program crid="crid: //hbc . com/ bear /woods" /> 
<ProgramURL>dvb: //I . 4ee2 . 3f 4/</ProgramURL> 

<PublishedStartTime>2002-0 6-05119:00: 00. 00+01 :00</PublishedStartTime> 
<PublishedDuration>PT60H</PublishedDuration> 
< /Broadcast Event > 
</ProgramLocationTable> 
</ProgramDescription> 

Insert instance metadata in the ProgramLocationTable to specify why the user might select that particular instance of 
the programme (e.g. edited for language). 

Search 

The PDR will use the information from the Programlnformation and ProgramLocation tables to render an EPG. The 
ProgramLocation table is used by the PDR to know the expected time and channel where the programmes will be 
shown, and the Programlnformation table is used to provide the location-independent information about each 
programme (such as title and synopsis). 

The user can then navigate around this EPG to find content that they wish to acquire. 
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Select 

Once the user lias found something they wish to acquire, they have the choice of acquiring any instance of the 
programme, or the specific instance they chose from the EPG. 

If the user selects "any instance" of the programme, the PDR uses the GRID from the Programme element of the 
BroadcastEvent table to start its acquisition process. 

If the user selects the "this specific instance" of the programme, the PDR uses the GRID from the Programme element 
and the Instance Metadata Identifier from the InstanceMetadatald element. 

In the following example, we assume that the user has selected episode one of foxes (GRID 

"crid://hbc.com/foxes/episoder') and that they want this specific instance (Instance Metadata Identifier "imi:fel_r') 
rather than any other showing. 

Locate 

Given the GRID for the chosen programme, the location resolution functional unit will return a list of GRIDs that refer 
to showings of this programme. This relies on the fact that the location resolution data is made available to the box. 

In the XML instance it can be seen that the GRID has two locators associated with it, those of the first showing and its 
repeat. 

Note that the syntax of the locator is not specified here. For purposes of illustration, a locator has been created by 
appending an existing DVB locator with an "@" and a string to express time and duration according to ISO 8601 [16]. 

Acquire 

The local storage management function could use any alternative locators to resolve recording conflicts when the user 
has not selected a preference for a specific instance. The chosen locator will then be used to tune to the specified 
channel at the specified time and record for the specified duration. When the user has selected a specific instance, the 
PDR will use the Instance Metadata Identifier to decide which locator to use for acquisition. 

Looking at the chosen example, the PDR would use the first locator in the content referencing result, because it has an 
Instance Metadata Identifier of "imi:fel_r'. 

To ensure that the content is recorded the system must monitor for changes in the location of the content. For example, 
the programme may be moved to a different channel. This may involve re-resolution of the GRID. 

An interesting scenario to demonstrate is how a PDR can cope with changes in scheduling. Using the previous example, 
here is the content referencing result after a schedule change for the chosen episode of "Foxes". 

<ContentRef erencingTable> 

<Result CRID="crid: //hbc . com/f oxes/ episode 1 " status=" resolved" 
complete="true" acquire="any "> 
<LocationsResult> 
<Locator instanceMetadataId="imi : f ell "> 

dvb://1.4ee2.3f4;4f5@2002-06-05T18:21:00.00+01:00/PT00H2 9M 
</Locator> 
<Locator instanceMetadataId="imi : f el2 "> 

dvb://1.4ee2.3f4;4f5@2002-06-08T21:30:00.00+01:00/PT00H2 9M 
</Locator> 
</LocationsResult> 
</Result> 
</ContentReferencingTable> 

In the above example, the first showing of episode one is delayed by twenty minutes. The PDR can still acquire the first 
showing because it can decide which locator to use by using the Instance Metadata Identifier "imi:fel_r'. 

The acquisition function of the PDR will need to use both the GRID ("crid://hbc. com/foxes/episode 1") and the Instance 
Metadata Identifier ("imi:fel_r') to perform successful acquisition. This is because Instance Metadata Identifiers are 
only unique within the scope of one GRID, so for example the "imi:fel_r' Instance Metadata Identifier might also be 
used with another GRID. 
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View 

Once the chosen episode has been acquired it is made available for viewing. As the viewer may want to view the 
associated metadata at the time of playback, the system should store the associated metadata at the time of selection or 
capture. If the metadata changes between selection and playback, it may be necessary to use version or timestamp 
information to present useful information to the user. 

To allow users to know what they actually have recorded on their PDR, at least a minimal set of metadata needs to be 
kept with the content. In our example that could be the Programlnformation tables, allowing the user to see title and 
synopsis of programmes that have been recorded. 

Finish 

This may involve a user preference system storing information about the viewing of this series or episode. This 
information could then be used by an agent to determine the preferences of the user. An extensive example of usage 
history can be found in annex A. 

7.5 Phase 1 example: Allow the user to select content from an 
on-demand content offer with associated pricing 
information, or seek lowest cost offer 

Publish 

A service provider will publish an on-demand content offer with associated pricing information. The offer is available 
via a broadcast channel (offer is pushed) or via an Internet server (offer is pulled). 

For 500 Yen, this content can be played 5 times during 1 month as soon as content has been acquired. The commercial 
offer is valid during two month starting June, 1, 2005. Content is available for one month starting July, 1, 2005. 

For 200 Yen, this content can be played only once. 

The Immediate Viewing flag being set to "true", this content is subject to rights managements restrictions (see RMP). 

<TVAMain xml : lang=" ja" xmlns="urn : tva :metadata: 2005" 

xmlns :mpeg7="urn :mpeg :mpeg7 : schema : 2 005" xmlns : xsi="http : //www . w3 . org/2001/XMLSchema- 
instance" xsi : schemaLocation="urn : tva : metadata : 2 005 schemas/tva_metadata_3-l_vl31 . xsd"> 
<P r ogr amDe script! on > 

<P rogramin format ionTable> 

<ProgramInf ormation programId="crid: //www . inter galactic . com/f oxes"> 
<BasicDescription> 

<Title type="main">Foxes - The Movie</Title> 

<Synopsis>Action-packed debut movie in which the Fox is elected governor of 
the State of California . </Synopsis> 
<Keyword>Fox</Keyword> 

<Genre href="urn: tva : metadata : cs : FormatCS :2005:3.5.7.3" type="main" /> 
</BasicDescription> 
< /P rogramin format ion> 
</ProgramInf ormationTable> 
<ProgramLocationTable> 
<OnDemandProgram> 

<Program crid="crid : //www .inter galactic. com/f oxes " /> 
<InstanceDescription> 

<Title type="main">Foxes - The Movie</Title> 
<PurchaseList> 

<PurchaseItem start="2 005-0 6-01T00 : 00 : 00" end="2 005-07-31T00 : 00 : 00"> 
<Price currency=" JPY">500</Price> 
<Purchase> 

<Pur chase Type 

href =" urn : tva : metadata : cs : PurchaseTypeCS : 2 004 : playForPeriod" /> 
<QuantityUnit href="urn: tva : metadata : cs : UnitTypeCS : 2 004 : month" /> 
<QuantityRange max="l"/> 
</Purchase> 
<Purchase> 

<Pur chase Type 
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href="urn : tva : metadata : cs : PurchaseTypeCS : 2 004 : playCounts" /> 
<QuantityUnit href =" urn : tva : metadata : cs : UnitTypeCS : 2 004 : plays " /> 
<QuantitYRange max="5"/> 
</Purchase> 
<PricingServerURL>http : //foxes . ondemand . com/prices /</PricingServerURL> 
</PurchaseItem> 
</PurchaseList> 
</InstanceDescription> 

<PublishedDuration>P14 5M</PublishedDuration> 

<StartOfAvailability>2 005-07-01119:00: 00. 00+0 l:00</StartOfAvailability> 
<EndOfAvailability>2 005-07-31119:00: 00. 00+0 l:00</EndOfAvailability> 
<ImmediateViewing value="true" /> 
</OnDemandProgram> 
<OnDemandProgram> 

<Program crid="crid : //www . interga lactic . com/ foxes " /> 
<InstanceDescription> 

<Title type="main">Foxes - The Movie</Title> 
<PurchaseList> 

<PurchaseItem start = "2 005-0 6-01T00 : 00 : 00" end="2 005-07-31T00 : 00 : 00"> 
<Price currency=" JPY">2 00</Price> 
<Purchase> 

<Pur chase Type 

href = "urn : tva : metadata : cs : PurchaseTypeCS : 2 004 : playCounts" /> 
<QuantityUnit href="urn: tva : metadata : cs : UnitTypeCS : 2 004 : plays " /> 
<QuantitYRange max="l"/> 
</Purchase> 
<PricingServerURL>http : //foxes . ondemand . com/prices /</PricingServerURL> 
</PurchaseItem> 
</PurchaseList> 
</InstanceDescription> 

<PublishedDuration>P14 5M</PublishedDuration> 

<StartOfAvailability>2 005-07-01T19:00:00.00+01:00</StartOfAvailability> 
<EndOfAvailability>2 005-07-31T19:00:00.00+01:00</EndOfAvailability> 
<ImmediateViewing value="true" /> 
</OnDemandProgram> 
</ProgramLocationTable> 
</ProgramDescription> 
</TVAMain> 

Search 

If a user is looking all the offers under a given price ceiling for a particular movie (e.g. 1 000 Yens), he will either look 
at the prices proposed through the pushed offer, or retrieve additional information from the web server. The information 
will be returned as shown above. The user can then select the offer of his choice. 



Locate, Acquire, View, Finish 
According to the TV-Anytime processes. 

7.6 Phase 1 example: Notify the user of something interesting 
based on their profile 

Publish 

A content creator will publish a CRID that represents a programme. The same or different service provider will publish 
metadata that describes this programme. The same or different service provider will publish location resolution data that 
describes where and when the programme may be viewed. 
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In this example we will use a soccer game "World cup, Japan and Russia" which starts 4:30am EST June 14, 2002. The 
PDA is aware that the user has a preference for this type of content because of his profile that is stored on the PDR. 

<ProgramDescription> 

<ProgramInf ormationTable> 

<ProgramInf ormation programId="crid : 1 1 too . com/soccer/worldcup/ japan- russia"> 
<BasicDescription> 

<Title tYpe="main"> 

2002 FIFA World cup soccer game 
</Title> 
<SYnopsis length=" short "> 

World cup soccer game, Japan versus Russia 
</Synopsis> 

<Keyword>World Cup</KeYword> 
<KeYword> soccer </Keyword> 
<KeYword>f ootball</Keyword> 
<Key wo r d> Japan </KeYwor d> 

<Genre href = "urn : tva :metadata : cs : FormatCS : 2005 : 3 . 2 . 3 . 12 " 
tYpe="main" /> 

<Genre href = "urn : tva :metadata : cs : FormatCS : 2005 : 3 . 2 . 3" 
tYpe=" secondary "/> 
< /Ba s i cDe script! on > 

<MemberOf xsi : type="MemberOf Type" crid="crid://foo. com/ soccer /wo rldcup"/> 
</ProgramInf ormation> 
</ProgramInf ormationTable> 
</ProgramDescription> 

InstanceMetadata can be used to allow a PDR to build an EPG or to inform the user of the approximate schedule of an 
airing. The BroadcastEvent table in the instance metadata is used for that purpose. It is A^OT there to signal to the PDR 
where and when a particular programme really can be found: that is the job of content referencing and location 
resolution mechanism. As stated before, the metadata is used mainly for attraction purposes. An example XML snippet 
of a BroadcastEvent table is given below: 

<ProgramLocationTable> 

<BroadcastEvent servicelDRef = "hbcl00022311"> 

<Program crid=" crid: / / too . com/soccer/worldcup/ japan-russia" /> 
<ProgramURL>dvb: //I . 4ee2 . 3f 5/</ProgramURL> 

<PublishedStartTime>2001-04-05T21 : 00:00.00+01: 00</PublishedStartTime> 
<PublishedDuration>PT30H</PublishedDuration> 
<Live value="f alse" /> 
<Repeat value="false"/> 
<FirstShowing value="f alse" /> 
<LastShowing value=" false" /> 
<Free value="false"/> 
< /Broadcast Event > 
</ProgramLocationTable> 



Search 

The FilteringAndSearchPreferences of the user's profile will be used by the PDR to filter and search for relevant 
programmes automatically. Every time the PDR gets a newer version of an EPG, or at other specified times, the PDR 
searches for programmes that matches the user's preferences. According to the results of this profile match, the PDR 
may issue a notification to the user. This notification may be issued via email, screen indication, or some other method 
that was selected by the user. The notification may include both programme and instance information. With this 
notification, the PDR may urge the user to perform some relevant action in the next phase. 

<UserDescription> 
<UserPref erences> 

<mpeg7 :UserIdentif ier protected="true"> 

<mpeg7 :Name xml : lang="en">Jay</mpeg7 :Name> 
</mpeg7 :UserIdentif ier> 
<mpeg7 : FilteringAndSearchPref erences> 

<mpeg7 :ClassificationP references pref erenceValue=" 12 "> 
<mpeg7 : Language>en</mpeg7 : Language> 
<mpeg7 : Genre href ="urn : tva : metadata : cs : FormatCS :2005:3.2.3.12"/> 
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<mpeg7 : Sub ject>Japan</mpeg7 : Sub ject> 
</mpeg7 : Class ificationPreferences> 
</mpeg7 : FilteringAndSearchPref erences> 
</UserPref erences> 
</UserDescription> 



Locate, Acquire, View, Finish 
Not relevant for this scenario. 



7.7 Phase 1 example: Personal Channel Service at my PDR 

A viewer wants to set his/her week's watching schedule, after electronic guide information from many service providers 
has been stored at PDR. However he/she does not want to navigate all the programme information at programme guide 
application for setting watching schedule. 

Also, the viewer wants PDR to generate the viewer's own schedule customized to his/her various preference or lifestyle. 
This generating procedure can be done at PDR automatically based on the viewer's usage history and user preference 
information. 

Then the generated personal channel and its programme information provides following guide at programme guide 
appHcation: at Monday 8:00 P.M. to 9:00 P.M., News Channel news, and at 9:00 to 10:00 P.M., special action movie 
from HBO, etc. Surely, this re-arranged programme schedule combined from many broadcasting providers builds into 
one personal channel. 

The personal channel at PDR provides above rescheduled programmes by a user's preference at the user's preferred date 
on the personal channel. 

For this personal channel at PDR, the following operations must be done by a user's PDR in sequence order. 

A user's usage history is stored. 

The user's preference for date (day and time), genre per date, and programme title is extracted by analyzing the 
user's usage history. 

A new channel for the user is generated. 

Programmes are determined to be broadcast on the personal channel at the user's preferred date by the user's 
preference information. 

A new personalized InstanceDescriptionMetadata is generated for informing the user that a new programme 
instance is included in the personal channel. 

When this personal channel service is compared with an existent preference-based-EPG service, the object of personal 
channel service is to provide a new channel that broadcasts newly scheduled programmes according to user's 
preference, but the object of preference-based-EPG service is to make user find easily his/her preferred programmes 
among the enormous programmes on the EPG. 

That is, the personal channel service relocates programmes by a user's title and date preference and provides the 
programmes only on the personal channel, but the preference-based-EPG service just differently represents the 
programme lists of all channels according to the degree of user preference. 

For a general understanding about the personal channel service, figure 13 shows a conceptual drawing of personal 
channel service. A common service provider generates and provides instance description metadata to PDRs. Then a 
PDR uses this instance description metadata to render the EPG for informing a user of the schedule of usually broadcast 
programmes. In addition to the usage, in the personal channel service, personal channel controller in the PDR uses the 
instance description metadata for choosing user preferred programmes for personal channel, and then stores new 
instances of the selected programmes in the personalized instance description metadata. 
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Figure 13: Conceptual drawing of Personal Channel 

In detail, inter-operations between a service provider and a user for the personal channel service are shown in figure 12. 
As explained above, a service provider offers CRID, location resolution data and metadata such as 
ContentDescriptionMetadata (including Programlnformation, Grouplnformation), InstanceDescriptionMetadata 
(including ProgramLocation, Servicelnformation). A user's PDR simply can render EPG using the metadata, and then 
the user can choose and watch a programme when the programme has been already scheduled by the service provider. 
But in the personal channel service, the personal channel controller in the PDR relocates programmes according to user 
preference on the personal channel. And then the new schedule of programmes for the personal channel is informed to 
users by including new instances in the personalized instance metadata. 

In the following, we explain how the personal channel service may work using the content referencing specification 
(S-4) and Metadata specification (S-3). We follow all the processes identified in a TV-Anytime System, e.g. Publish, 
Search, Select, Locate, Acquire, View, and Finish. In the personal channel service, a new process, PDRs Search and 
Select, is included after the Publish process because the PDR rearranges programmes provided by service providers and 
recreate Instance Description Metadata locally for the virtual channel. 
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Figure 14: Interaction between Service Provider and Client 



Publish 



A content creator will publish a CRID that represents a programme, the same or different service provider will publish 
location resolution data that describes where and when the programme may be viewed, and the same or different service 
provider will publish programme description metadata and programme instance metadata. 

For the personal channel service, ContentDescriptionMetadata (including Programlnformation, Grouplnformation) and 
InstanceDescriptionMetadata (including ProgramLocation, Servicelnformation) must be offered by the service provider, 
and UserPreference metadata must be provided by the PDR, because personal channel controller in the PDR chooses 
programmes which will be broadcast on personal channel by programme description metadata including programme 
group information, programme instance metadata, and user preference data. 
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Of the three kinds of metadata, the first metadata, ContentDescriptionMetadata (including Programlnformation, 
Grouplnformation) is general information about a piece of content that does not change regardless of how the content is 
published or broadcast. 

The following XML snippets show Grouplnformation element of a Korean Drama, "Sangdo" which has several 
episodes, and a few Programlnformation elements that contain information for each episode of the group, "Sangdo". 

<ProgramDescription> 

<P rogramin format ionTable> 

<ProgramIn format ion programId="crid : //imbc . com/ sangdo /episode 17 "> 
<BasicDescription> 

<Title> Sangdo_17 </Title> 

<Synopsis> The one where Sangdo is embarrassed with the rumour</Synopsis> 
<Genre href = "urn : tva :metadata : cs : FormatCS : 2005 : 3 . 4 . 2 . 1 " type="main" /> 
</BasicDescription> 
</ProgramInf ormation> 

<P rogramin format ion programId="crid : //imbc . com/ sangdo /episode 18 "> 
<BasicDescription> 

<Title> Sangdo_18 </Title> 

<Synopsis> The one where Sangdo sold his clothes cheaply </Synopsis> 
<Genre href = "urn : tva :metadata : cs : FormatCS : 2005 : 3 . 4 . 2 . 1" type="main"/> 
</BasicDescription> 
</ProgramInf ormation> 
</ProgramInf ormationTable> 
<GroupIn format ionTable> 

<GroupInf ormation groupId="crid : //imbc . com/ sangdo /several" ordered="true" 
num0fltems="2"> 

<GroupType xsi : type="ProgramGroupTYpeType" value="series"/> 
<BasicDescription> 

<Title>Sangdo</Title> 

<SYnopsis>Several episodes of Sangdo</Synopsis> 

<Genre href = "urn : tva :metadata : cs : FormatCS : 2005 : 3 . 4 . 2 . 1 " type="main"/> 
< /Bas i cDe script! on > 
</GroupInf ormation> 
</GroupInf ormationTable> 
</ProgramDescription> 

The second metadata, InstanceDescriptionMetadata is also offered by the service provider. Instance 
DescriptionMetadata (including ProgramLocationTable) can be used to allow a PDR to build an EPG or to inform the 
user of the approximate schedule of an airing. The BroadcastEvent element in the instance description metadata is used 
for that purpose. 

For the personal channel service, the InstanceDescriptionMetadata plays a great role in addition to the general EPG 
function. InstanceDescriptionMetadata is referred in PDR's selecting a programme for a personal channel according to 
the user preference and used in announcing newly included channel and programme instances to the user. That will be 
explained in more detail under PDR's Search and Select. 

The followed XML snippet shows ProgramLocation table that holds information of each programme instance and 
Serviceinf ormation table that contains channel information such as service id, service name, owner, and so on. 

<ProgramDescription> 

<ProgramLocationTable> 

<BroadcastEvent serviceIDRef="Chl"> 

<Program crid="crid : //imbc . com/ sangdo /episode 17 " /> 
<ProgramURL>dvb: //I . 4ee2 . 3f 4/</ProgramURL> 

<PublishedStartTime>2002-04-22T22 : 00 : 00</PublishedStartTime> 
<PublishedDuration>PT50M</PublishedDuration> 
< /Broadcast Event > 
<BroadcastEvent service IDRef =" Chi" > 

<Program crid="crid : //imbc . com/ sangdo /episode 18 " /> 
<ProgramURL>dvb: //I . 4ee2 . 3f 4/</ProgramURL> 

<PublishedStartTime>2002-04-23T22 : 00 : 00</PublishedStartTime> 
<PublishedDuration>PT50M</PublishedDuration> 
< /Broadcast Event > 
</ProgramLocationTable> 
<ServiceInf ormationTable> 

< Service In formation serviceId="Chl "> 
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<Name>MBC</Name> 

<Owner>MBC</ Owner > 
< /Service I nformation> 
</ Service InformationTable> 
< /P r ogr amDe script! on > 



The third metadata, UserPreference metadata is automatically generated by User Profile in the PDR and it is an essential 
information to determine an airing date and programme on the personal channel. UserPreference metadata for the 
personal channel service uses minimal preference information such as title preference and genre preference per date. 

The followed XML snippet shows FilteringAndSearchPreferences that specifies a user's filtering and/or searching 
preference for audio-visual content. These preferences are specified by creation-, classification-related properties of the 
content. 

<UserDescription> 
<UserPreferences> 

<mpeg7 :UserIdentif ier> 

<mpeg7 :Name xml : lang="en">etri</mpeg7 : Name> 
</mpeg7 :UserIdentif ier> 
<mpeg7 : Filter ingAndSearchPreferences> 
<mpeg7 :CreationPreferences> 

<mpeg7 : Title pref erenceValue=" 99">sangdo</mpeg7 : Title> 
</mpeg7 : CreationPref erences> 
</mpeg7 : FilteringAndSearchPref erences> 
<mpeg7 : FilteringAndSearchPref erences> 
<mpeg7 :ClassificationPreferences> 

<mpeg7:Genre href = "urn : tva :metadata : cs :FormatCS : 2005 : 3 . 4 . 2 . 1" 
pref erenceValue=" 80" /> 
</mpeg7 : Classif icationPref erences> 
<mpeg7 :Pref erenceCondition> 

<mpeg7 : Time recurrence="weekly"> 

<mpeg7 : TimePoint>2 002-0 4-2 3T11 :00</mpeg7 :TimePoint> 
<mpeg7 :Duration>PTlH</mpeg7 :Duration> 
</mpeg7 : Time> 
</mpeg7 :Pref erenceCondition> 
</mpeg7 : FilteringAndSearchPref erences> 
</UserPref erences> 
</UserDescription> 



PDR's Search and Select 

After the three kinds of metadata are offered, personal channel controller in the PDR makes a new channel as personal 
channel with the exception of usual broadcast, cable, and satellite channels. Personal channel controller also selects 
programmes that are going to be broadcast on personal channel by user's preference data, programme description 
metadata, and programme instance metadata. 

For this programme selection process, the following operations must be done by the Personal Channel Controller. 

• First, a user's preferred date (day and time) is checked. 

• Second, which genre is preferred at the date is checked. 

• Third, a programme that is included in the preferred genre and has higher title preference is chosen as a new 
programme for personal channel. 

• Fourth, the information about a newly included channel and its new instance is included in the 
InstanceDescriptionMetadata ( ProgramLocation ) to announce to the user. 

At fourth step of above operations, a set of new service information and broadcast event information are generated and 
added into InstanceDescriptionMetadata. 
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Programmes on a personal channel make use of the same content referencing & location resolution mechanism as for 
regular broadcast or on-demand content. For each programme in a personal channel, the PDR generates a new locator 
pointing to the stored location of the programme and updates the local content referencing table and program location 
table. 

The included XML snippet shows an original instance of the selected programme scheduled in the "MBC" channel and 
a newly included channel, that is "PERSONAL", and its new instance. 

<ProgramDescription> 

<ProgramLocationTable> 

<BroadcastEvent service IDRef=" Chi "> 

<Program crid="crid : //imbc . com/ sangdo/ episode 18 " /> 
<ProgramURL>dvb: 111 . 4ee2 . 3f 4/</ProgramURL> 

<PublishedStartTime>2002-04-16T22 : 00 : 00 . 00</PublishedStartTime> 
<PublishedDuration>PT50M</PublishedDuration> 
< /Broadcast Event > 
<BroadcastEvent service lDRef="Ch2"> 

<Program crid="crid : //imbc . com/ sangdo /episode 18 " /> 
<ProgramURL> MY_PDR/personal/</ProgramURL> 

<PublishedStartTime>2002-04-20Tll:00:00.00</PublishedStartTime> 
<PublishedDuration>PT50M</PublishedDuration> 
< /Broadcast Event > 
</ProgramLocationTable> 
<ServiceInf ormationTable> 

<Service Information serviceId="Chl "> 
<Name>MBC</Name> 
<Owner>MBC</ Owner > 
< /Service I nformation> 

< Service In format ion service ld="Ch2 "> 
<Name>PERSONAL</Name> 
<Owner>My_PDR< /Owner > 
</ Service Information> 
</ Service InformationTable> 
</ProgramDescription> 



User's Search 

After the PDR's search and select process, PDR can use Programlnformation metadata and newly generated 
ProgramLocation metadata to render an EPG on the User Interface in PDR. The EPG also represents the personal 
channel information like other channels. 

Next to the EPG generation, the user can navigate around this EPG and consume audiovisual contents. This audiovisual 
content consumption history for a user is described in the UsageHistory as lists of the actions performed by the user 
over an observation period, which can subsequently be used by the User Profile in PDR to generate user preferences. 

As the above general case, when a user surveys the programme information and group information of a specific 
programme, that affects the user's preference positively because this survey presents the user's interest in the 
programme. For this positive effect on the user's preference, a new UserAction item is included in the UsageHistory in 
the User Profile, and then the UsageHistory is used by the User Profile to fill the user preference metadata table which 
specially includes preference for programme title, date, and genre per date. 

The followed XML snippet shows UsageHistory that contains UserAction item whose type is ViewGuide. 

<UserDescription> 

<UsageHistory i d=" usage -history-001" allowCollection="true"> 
<mpeg7 :Userldentif ier protected="true"> 

<mpeg7 :Name xml : lang="en">etri</mpeg7 : Name> 
</mpeg7 :UserIdentif ier> 

<mpeg7 :UserActionHistory protected="f alse"> 
<mpeg7 :ObservationPeriod> 

<mpeg7 : TimePoint>2 002-04-1 8T10 : 00</mpeg7 :TimePoint> 
<mpeg7 :Duration>PT3H</mpeg7 :Duration> 
</mpeg7 : ObservationPeriod> 

<mpeg7 :UserActionList id="ua-list-001" numOf Instances="l" totalDuration="PT20M"> 
<mpeg7 : ActionType href =" urn :mpeg :mpeg7 : cs : ActionTypeCS :2004:3.4"> 
<mpeg7 :Name>ViewGuide</mpeg7 :Name> 
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</mpeg7 :ActionType> 
<mpeg7 :UserAction> 
<mpeg7 : ActionTime> 
<mpeg7 :MediaTime> 

<mpeg7 :MediaTimePoint>2002-04-18T10 : 05 : 00</mpeg7 :MediaTimePoint> 
<mpeg7 :MediaDuration>PT00H20M</mpeg7 :MediaDuration> 
</mpeg7 :MediaTime> 
</mpeg7 :ActionTime> 

<mpeg7 : P rogrami dent i fie r organization="TVAF" 

tYpe="CRID">crid : //imbc . com/ sangdo/ several </mpeg7 : P rogrami dent if ier> 
</mpeg7 : UserAction> 
</mpeg7 :UserActionList> 
</mpeg7 :UserActionHistory> 
</UsageHistory> 
</UserDescription> 

In the User's Search process, the user is more willing to choose an instance for the personal channel, because the 
personal channel provides a user preferred programme at the preferred date using the UserPreference information 
explained above. 

User's Select 

During a user's navigation, if the user has found a programme that the user wishes to acquire from the personal channel, 
the user selects the programme on the EPG. 

The specific instance from personal channel is selected using both the GRID from the Programme element and the 
Instance Metadata Identifier from the InstanceMetadatald element. This is because Instance Metadata Identifiers are 
only unique within the scope of one GRID. 

In this personal channel scenario, we assume that a user has selected the 18* episode of Sangdo, a Korean drama whose 
GRID is "crid://imbc.com/sangdo/episodel8", and that the user wants this specific instance from personal channel 
(Instance Metadata Identifier "imi:my_PDR/etri2") rather than any other showing. 

Locate 

Given the GRID for the chosen programme, the location resolution functional unit will return a list of locators that refer 
to showings of this programme. This relies on the fact that the location resolution data is made available to the box. 

In the following XML instance, it can be seen that the GRID has two locators associated with it, those of the general 
DVB and personal channel. 

<ContentRef erencingTable> 

<Result CRID="crid: //imbc . com/sangdo/episodel8" 
status="resolved" complete="true" acquire="anY"> 
<LocationsResult> 
<Locator> 

dvb://1.4ee2.3f4; 4 f 5(32002-04-1 6T22 : 00 : 00 . 00/PT00H50M 
</Locator> 
<Locator> 

My_PDR/personal /sangdol8@2002-04-20Tll:00:00.00 /PT00H50M 
</Locator> 
</LocationsResult> 
</Result> 
</ContentRef erencingTable> 



Acquire 

As explained in the User's Select process, because the user has selected a specific instance from the personal channel, 
the PDR would use the second locator in the content referencing result. And the chosen locator will then be used to tune 
to the specified channel at the specified time and record for the specified duration. The PDR will use the Instance 
Metadata Identifier to decide which locator to use for acquisition. 
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Looking at the chosen example, the PDR would use the second locator in the content referencing result, because it has 
an Instance Metadata Identifier of "inii:my_PDR/etri2". And the chosen locator will then be used to tune to the 
specified channel at the specified time and record for the specified duration. 

View 

Once the chosen episode has been acquired it is made available for viewing. 

Finish 

In this process, storing information about the viewing of this series or episode in the usage history data is done by PDR. 

7.8 Phase 1 example: Programme made up of segments from 
multiple providers and maintain the latest news on my PDR 

For this example, there are two cases: 

• A programme has been pre-recorded and is delivered at a scheduled time and associated with a group CRID. 
This programme is made of several programmes having their own CRID federated under the umbrella of the 
overall programme groupCrid. The user-personalized service knows the programme elements of the user 
interest, which CRIDs will be used to allow the capture and update of the desired programme elements. 

• A live News Channel or Sport Channel programme each identified by a CRID is being transmitted and 
recorded in its entirety. Segmentation information is provided after the programme has ended that will allow 
the user to automatically access the segments of his interest has previously defined as part of his subscription 
profile. 

This scenario explores the second case. 

A viewer has subscribed to a "latest, personalized news" service from their provider. They want their world news from 
News Channel, and their sports news from Sport Channel. They expect to be able to view only the news requested from 
each of these providers be captured and compiled into a virtual programme that begins with News Channel then 
automatically goes to Sport Channel. They also require that they can jump between items using their remote control and 
if required view a list of the available segments of news in a list format- that describes the content in each clip. 

They have also requested that the business news segments be updated at every available opportunity, which means that 
each bulletin will be recorded in its entirety. The PDR may be configured to remove content that is not anymore used. 

Latest news and sports 



ProgramCompilation 
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Seg .CNN itemi Seg, CNN item2 Seg. Eurosporls itemi Seg. Eurosporls itern2 Seg. Eurosports item3 



SegmentGrouplnformation 

Figure 15: Compilation of updated segments from multiple providers 
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Publish 

A content creator will publish a CRID that represents a programme. The same or a different service provider will 
publish metadata that describes this programme. The same or a different service provider will publish location 
resolution data that describes where and when the programme may be viewed. 

The included XML snippets show an almost minimal way to describe this schedule. Two metadata tables are needed to 
describe the schedule. The ProgramlnformationTable contains information for each of the different programmes. It is 
worth noting that the ProgramLocation table is NOT there to signal to the FDR where and when a particular programme 
really can be found: that is the task of content referencing and location resolution mechanism. 

In this example we will use News Channel latest news and Sport Channel latest sport. The PDR is aware that the user 
has a preference for this type of content because of his latest news subscription profile that is stored on the PDR. Both 
News Channel and Sport Channel programmes are described as ProgramCompilation in the GroupInformationTable. 

<TVAMain xml:lang="en" 
publisher="TVA" 

publicationTime="2 002-0 8-0210 9:30:47-05: 00" 
right sOwner="TVA" 
version="0"> 

<CopyrightNotice>TVA</CopYrightNotice> 
<P r ogr amDe script! on > 

<ProgramInf ormationTable> 

<ProgramIn format ion programId="crid : //cnn . com/latestnews"> 
<BasicDescription> 

<Title tYpe="main">News Channel Business update</Title> 
<SYnopsis length=" short "> 

Latest version of the News Channel business news 
</SYnopsis> 
</BasicDescription> 
</ProgramInf ormation> 

<ProgramIn format ion programId="crid : //euro sport . com/latest "> 
<BasicDescription> 

<Title tYpe="main">Sport Channel sport update</Title> 
<SYnopsis length=" short "> 

A collection of the latest sport news hy Sport Channel 
</Synopsis> 
</BasicDescription> 
</ProgramInf ormation> 
</ProgramInf ormationTable> 
<GroupIn format ionTable> 

<GroupInf ormation groupId="crid: //f oo . bar . com/gary" ordered="true" numOf Items="2 "> 
<GroupTYpe xsi : tYpe="ProgramGroupTYpeTYpe" value="programCompilation" /> 
<BasicDescription> 

<Title tYpe="main"> 

Gary's latest business and sports news 
</Title> 
Oynopsis length="short "> 

Mix from News Channel business news and Sport Channel sports 
</Synopsis> 
</BasicDescription> 
</GroupInf ormation> 
</GroupInf ormationTable> 
</ProgramDescription> 
</TVAMain> 

The segmentation metadata will be broadcast after each programme and it is associated programme 
information/programme location metadata. The following XML snippet shows the segmentation metadata for the latest 
news and sports. It references the News Channel latest news programme, which contains references to two segments 
and the Sport Channel latest sport programme, which contains references to three segments. The two and three latest 
segments and the segment group are described as follows: 
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<TVAMain xml:lang="en" 
publisher="TVA" 

publicationTime="2 002-0 8-0210 9:30:4 7-05: 00" 
right sOwner="TVA" 
version="0"> 

<CopYrightNotice>TVA</CopyrightNotice> 
<ProgramDescription> 

< Segment In formationTable> 
<SegmentList> 

< Segment In format ion segment Id="Slff-ef a 5- e5 67-12 ff"> 
<ProgramRef crid="crid: //cnn. com/latestnews " /> 
<Description> 

<Title xml : lang="en">News Channel Latest Business News</Title> 
Oynopsis xml : lang="en">Fox goes to the stockmarket</Synopsis> 
</Description> 
< Segment Locat or > 

<MediaRelIncrTimePoint mediaTimeUnit="PTlN2 5F">1377 7</ 
MediaRe liner TimePoint> 

<MediaIncrDuration mediaTimeUnit="PTlN2 5F">167 8 0</MediaIncrDuration> 
</ Segment Locat or > 
< /Segment I nformation> 

< Segment In format ion segment Id="S2ff-efa5-e567-34ff"> 
<ProgramRef crid="crid: //cnn . com/latestnews " /> 
<Description> 

<Title xml : lang="en">News Channel Latest Business News</Title> 
<Synopsis xml : lang="en">Interview with Fox</SYnopsis> 
</Description> 
<Segment Locat or > 

<MediaRelIncrTimePoint mediaTimeUnit="PTlN2 5F">27 8 90</ 
MediaRe lIncrTimePoint> 

<MediaIncrDuration mediaTimeUnit="PTlN2 5F">2545 6</MediaIncrDuration> 
</ Segment Locat or > 
< /Segment I nformation> 

< Segment In format ion segment Id="S5ff-ef a 5- e5 67-12 ff"> 
<ProgramRef crid="crid://eurosport. com/ latest " /> 
<Description> 

<Title xml : lang="en">Sport Channel Latest Sports</Title> 
<Synopsis xml : lang="en"> 

Fox wins the tennis at the Paris Open 
</SYnopsis> 
</Description> 
< Segment Locat or > 

<MediaRe liner TimePoint mediaTimeUnit="PTlN2 5F"> 
12901 

</MediaRelIncr TimePoint > 
<MediaIncrDuration mediaTimeUnit="PTlN2 5F"> 

15470 
< /Media IncrDur at ion> 
</ Segment Locat or > 
< /Segment In formation> 

<Segment Information segmentId="S5f f-ef a5-e567-34f f "> 
<ProgramRef crid="crid://eurosport. com/ latest " /> 
<Description> 

<Title xml : lang="en">Sport Channel Latest Sports</Title> 
<Synopsis xml : lang="en"> 

Fox beats Tiger at Augusta. 
</SYnopsis> 
</Description> 
< Segment Locat or > 

<MediaRe liner TimePoint mediaTimeUnit="PTlN2 5F"> 
22291 

</MediaRel I ncr TimePoint > 

<Media IncrDur at ion mediaTimeUnit="PTlN2 5F"> 
26470 

< /Media IncrDur at ion> 
</ Segment Locat or > 
</ Segment Information> 

<Segment Information segmentId="S5f f-ee44-e567-34f f "> 
<ProgramRef crid="crid:/ /euro sport. com/ latest " /> 
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<Description> 

<Title xml : lang="en">Sport Channel Latest Sports</Title> 

<Synopsis xml : lang="en"> 

Fox loses sumo championship. 
</SYnopsis> 
</Description> 
< Segment Locat or > 

<MediaRe liner TimePoint mediaTimeUnit="PTlN2 5F"> 

25291 
</MediaRelIncrTimePoint> 
<MediaIncrDuration mediaTimeUnit="PTlN2 5F"> 

27885 
</MediaIncrDuration> 
</ Segment Locat or > 
< /Segment I nformation> 
</ Segment Li St > 
<SegmentGroupList> 

< Segment Group Information groupId="G234-ac4a-dddd-f f a9"> 
<ProgramRef crid="crid: / / too .bar . com/ gar y" /> 

<GroupType xsi : type=" Segment GroupTypeType" value="tableOf Contents " /> 
<Description> 

<Title xml : lang="en"> 

Items from News Channel and Sport Channel 
</Title> 
<Synopsis xml : lang="en"> 

Segment group containing segments from News Channel and Sport Channel 
</Synopsis> 
</Description> 

<Groups refList="Glll-4444-ffff-eeee G222-4444-f f f f-eeee"/> 
</ Segment GroupInformation> 
< Segment Group Information groupId="Glll-4 4 4 4-f f f f-eeee"> 
<ProgramRef crid="crid: //cnn . com/ latest news " /> 

<GroupType xsi : type=" Segment GroupTypeType" value="tableOf Contents " /> 
<Description> 
<Title xml : lang="en">Items from News Channel news</Title> 
<Synopsis xml : lang="en"> 

Segment group containing segments from News Channel 
</Synopsis> 
</Description> 

<Segments refList="S12f f-efa5-e5 67-12 ff 
S12ff-efa5-e5 67-34ff "/> 
</ Segment Groupin format ion> 

< Segment Group Information groupId="G222-4 44 4-f f f f-eeee"> 
<ProgramRef crid="crid : //euro sport . com/ latest sports" /> 
<GroupType xsi : type=" Segment GroupTypeType" value="tableOfContents"/> 
<Description> 

<Title xml : lang="en">Items from Sport Channel</Title> 
<Synopsis xml : lang="en"> 

Segment group containing segments from Sport Channel 
</Synopsis> 
</Description> 

<Segments ref List="S5f f-ef a5-e5 67-12f f 
S5ff-efa5-e567-34ff 
S5ff-ee44-e567-34ff "/> 
< /Segment Groupin format ion> 
</SegmentGroupList> 
</Segment Inf ormationTable> 
</ProgramDescription> 
</TVAMain> 



Search, Select 

Every time the PDR gets a newer version of an EPG, or at other specified times, the PDR searches for the appropriate 
programmes. According to the resuhs of this profile match, the PDR may capture the latest versions of the programmes 
and may also remove obsolete versions. 
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View 

Once the latest versions of the programmes and the associated segmentation information have been acquired it is made 
available for viewing. As the viewer may want to view the associated metadata at the time of playback, the system 
should store the associated metadata. To allow users to know what they actually have recorded on their PDR, at least a 
minimal set of metadata needs to be kept with the content. In our example that could be the ProgramlnformationTable, 
allowing the user to see title and synopsis of programmes that have been recorded, and the SegmentlnformationTable, 
allowing the use to see title and synopsis of the segments. 

Acquire 

The CRIDs of the programmes corresponding to the user subscription service must be "resolved" to a unique locator 
(channel/time/duration). (Similar to previous scenarios). 

Finisii 

Not relevant for this scenario. 

7.9 Phase 1 example: Usage scenarios for bi-directional 
metadata transport 

This example is for providing a usage scenario for bi-directional metadata transport using the existing TV-Anytime 
specification. HTTP and TCP/IP are used for protocols of metadata transport on IP network. 



Set Top Box 




Figure 16: Bi-directional metadata transport 



Publish 



A content creator will publish a CRID that represents a programme. The same or different service provider will publish 
metadata that describes this programme to metadata DB server. The metadata server aggregates and edits the metadata 
for establishing a metadata DB. 



ETSI 



65 ETSI TS 1 02 822-2 V1 .3.1 (2006-01 ) 

Search 

A query can be constructed to get programme information from the metadata server. 

The query might be: 

<get_Data> 
<QueryConstraints> 
<PredicateBag type='AND'> 

<BinaryPredicate fieldID= ' Genre ' fieldValue= ' Fiction ' /> 
<BinarYPredicate fieldID= 'Keyword' fieldValue= ' separation ' /> 
</PredicateBag> 
</QueryConstraints> 
<RequestedTables> 
<Table type= ' Programinf ormationTable ' > 
<SortCriteria fieldID= ' tvaf : Title ' /> 
</Table> 

<Table type= ' ProgramLocationTable ' /> 
</RequestedTables> 
</get_Data> 

Below is a possible result of such a query. 

<ProgramDescription> 

<ProgramInf ormationTable> 

<ProgramInf ormation programId="crid : //www .keti.re.kr/2002002"> 
<BasicDescription> 

<Title type="seriesTitle">Ghost mamma</Title> 

<Synopsis> A year later, Jiseok attempts to commit suicide, because he has 
been feeling guilty and lonely . </Synopsis> 
<Keyword>love story</Keyword> 
<Keyword>separation</Keyword> 
<Keyword>death</Keyword> 

<Genre href ="urn : tva : metadata :cs:ContentCS:2005:5.1" type="main" /> 
<Genre href ="urn : tva : metadata : cs : Format CS : 2005 : 3 . 1 " type=" secondary" /> 
<Pa rental Guidance> 

<mpeg7 : Parent alRating href="urn :mpeg :mpeg7 : cs :MPAAParentalRatingCS : G"> 

<mpeg7 : Name>G</mpeg7 : Name> 
</mpeg7 :ParentalRating> 
<mpeg7 :Region>UK</mpeg7 :Region> 
</ParentalGuidance> 

< Language type="original">ko</Language> 
<CreditsList> 

<CreditsItem role="urn :mpeg:mpeg7 : cs :MPEG7RoleCS : ANCHOR" > 

<PersonNameIDRef ref="PN61"/> 
</CreditsItem> 
<CreditsItem role="urn:mpeg:mpeg7 : cs :MPEG7RoleCS : ACTRESS"> 

<PersonNameIDRef ref="PN15"/> 
</CreditsItem> 
</CreditsList> 
<ProductionDate> 

<TimePoint>2 002</TimePoint> 
</ProductionDate> 

<ProductionLocation>ko</ProductionLocation> 
<CreationCoordinates> 
<CreationDate> 

<TimePoint>2 002 -03-2 l</TimePoint> 
</ Great ionDate> 

<CreationLocation>ko</ Great ionLocation> 
</GreationGoordinates> 
<Re lease In formation> 
<ReleaseDate> 

<DayAndYear>2 002-0 8-1 l</DayAndYear> 
</ReleaseDate> 

<ReleaseLocation>ko</ReleaseLocation> 
</ Release Information> 
</BasicDescription> 
</ProgramInf ormation> 
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</ProgramInf ormationTable> 
<ProgramLocationTable> 
<BroadcastEvent> 

<Program crid="crid: //www .keti.re.kr/2002002"/> 

<ProgramURL>null</ProgramURL> 

<PublishedStartTime>2002-08-01T16 : 41 : 00</PublishedStartTime> 

<PublishedDuration>P55M</PublishedDuration> 

<Live value="f alse"/> 

<Repeat value="false"/> 

<FirstShowing value="true" /> 

<LastShowing value=" false" /> 

<Free value="true"/> 
< /Broadcast Event > 
</ProgramLocationTable> 
</ProgramDescription> 



Select 

Search and navigation server issues CRIDs or trailers of desired contents and sends them to the PDR on a bi-directional 
network. 

Locate 

PDR selects a CRID and sends the CRID to a location resolution server on IP network. The location resolution server 
resolves a locator or a schedule according to the CRID and sends it to the PDR. 

Acquire 

The PDR accesses a content server according to the locator or records the contents according to the schedule of the 
desired contents. The local storage management function will use any alternative locators to resolve recording conflicts. 
The chosen locator will then be used to tune to the specified channel at the specified time and record for the specified 
duration. To ensure that the content is recorded the system must monitor for changes in the location of the content. 

View 

The desired contents have been acquired they are made available for viewing. As the viewer may want to view the 
associated metadata at the time of playback, the system should store the associated metadata at the time of selection or 
capture. 

Finisli 

This may involve a user preference system storing information about the viewing of the contents. This information 
could then be used by an agent to modify the preferences of the user. 

7.10 Phase 1 example: Profile 1 bi-directional multi-provider 
EPG 

This application shows the phase one TV-Anytime technologies for the combining of TVA metadata EPG sets from 
several metadata providers 

A service provider delivers a range of channels to subscribers on a uni -directional satellite network. They provide to 
their subscribers by aggregating (from a variety of sources) a CRID, title, genre, synopsis, rating, and location 
resolution information in their uni-directional stream. 

A third party is commercially contracted by the provider to supply (to the consumer via the return channel for an extra 
fee) an alternative and complete set of metadata for all feature films carried on that platform. The data set may duplicate 
information already available via the uni-directional service and fields may be identical to the previously delivered 
metadata but not necessarily so as the viewer is receiving added value (e.g. richer synopsis, rating/review, viewer 
ratings, cast lists etc.). The PDR user then selects and switches between either data set depending on their preference at 
that time. They activate capture for a particular film based on these data sets. 
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Publish 

The service provider publishes CRIDs and basic programme information. By virtue of the contractual relationship of the 
third party to the service provider, the third party metadata uses the same CRIDs as used by the service provider. 

Search 

The PDR will issue a query for every CRID received via the uni -directional network that the PDR wishes to get more 
information on: 

<get_Data> 

<QueryConstraints> 

<PredicateBag tYpe='OR'> 

<BinarYPredicate f ieldID= ' CRID ' fieldValue= ' crid: //broadcaster . com/ 1234 ' /> 

<BinarYPredicate f ieldID= ' CRID ' f ieldValue= ' crid: //broadcaster . com/2345 ' /> 

<BinaryPredicate fieldID=' CRID ' f ieldValue= 'crid: //broadcaster. com/2 434 ' /> 

</PredicateBag> 

</QueryConstraints> 

<RequestedTables> 

<Table tYpe= ' Programinf ormationTable ' > 
<SortCriteria fieldID= ' tvaf : Title ' /> 

</Table> 

<Table tYpe= ' Creditsinf ormationTable ' /> 

<Table tYpe= ' ProgramReviewTable ' /> 
< /Request edTables> 
</get_Data> 

Select/Locate/View/Finish 
As in previous examples. 

7.11 Phase 1 example: Related material recording 

The RelatedMaterialType DS can be used to link, for example, a promotional trailer to the content that it promotes. For 
example, a PDR may be viewing a piece of content and find a Related MaterialType DS in a data stream associated 
with the content. The encoding of the RelatedMaterialType into this data stream and the mechanism by which it is 
associated with the content is transport specific and outside the scope of TV A. 

The RelatedMaterialType DS provides the crid of the material as well as a description of how this material relates to the 
trailer being viewed. In this example, "Trailer" indicates that this content is a small preview of the whole programme. 
Using this information the PDR may, in an implementation specific way, present the user with a choice to record this 
programme. Other types of HowRelated include, "The making of and "Product purchase". Additionally, promotional 
text is included in the RelatedMaterial DS that the PDR may choose to display to provide the user with some context for 
why this programme may be chosen for recording. 

Publish 

Suppose a service provider publishes the following information as expressed by the XML snippet: 

<?xml version="l .0" encoding="UTF-8 " ?> 

<TVACont en t Links xmlns="urn : tva : metadata : 2 005 " xmlns :mpeg7="urn :mpeg :mpeg7 : schema : 2005" 
xmlns : xsi="http : //www . w3 . org/2 001/XMLSchema-instance" 
xsi : schemaLocation="urn : tva : metadata : 2 005 
tva_metadata_3-l_vl31 . xsd"> 
<RelatedMaterial> 

<HowRelated href="urn: tva : metadata : cs : HowRelatedCS : 2 005 "> 

<Name>Trailer</Name> 
</HowRelated> 
<MediaLocator> 

<mpeg7 :MediaUri>crid: //whatever</mpeg7 :MediaUri> 
</MediaLocator> 
<PromotionalText xml : lang="en">Record Foxes episode 6</PromotionalText> 



£75/ 



68 



ETSI TS 102 822-2 V1.3.1 (2006-01) 



</RelatedMaterial> 
</TVAContentLinks> 



Search/Select 

When the promotional item, in this case a trailer for "Foxes episode 6" is presented, the user is given an option to record 
the associated programme using the CRID in the MediaLocator. 

Note that this CRID can be used to retrieve further metadata, if so required. 

Locate/ Acq u i re/Vi ew/F i n is h 
As per previous examples. 

7.12 Phase 1 example: User profiling cookbook scenario and 
work-through application 

A viewer buys a TV-Anytime compliant device for their home. When they use the device for the first time they are 
encouraged, being offered cheaper content and other services, to plug the device into the phone line. During the set-up 
process they are also asked to enter some basic information about themselves. This includes their family group (couple), 
roughly where they live (Provo) and their date of birth (August 1966). Also at this time they are asked whether they 
would like the TVA device to recommend content to them. They say yes and are taken to a simple set-up screen where 
they choose: 

1) Favourite types of programmes (content) - News, Sport - athletics and game shows. 

2) Types of programmes (atmosphere) - alternative, breathtaking and inspirational. 

3) A range of people they like (key talent). - Sean Connery, Humphrey Bogart, Clint Eastwood and Meg Ryan. 
This information is moved into their user profile and some elements are made static and some can be updated. 

The viewer then starts to use the device. At each point in their use of the device their profile is being updated. 

a) At the start they request the capture of a drama "Pride and Prejudice" starring Colin Firth; 

b) they also press "record" for a programme called "Blue Moon", a documentary about the Solar System narrated 
by Colin Firth; and 

c) they then play and watch a local Provo News magazine programme which is transmitted with a second audio 
track in Spanish (which has been recorded for them already based on their initial favourites settings); 

d) a Bond movie starring Sean Connery is discovered by the agent in the box and offers the programme as a 
suggestion. 

During all of the above actions their user profile is being constantly updated. 

This is an example of how a section of the Schema looks once the viewer has performed the functions above: 



<TVAMain> 






<Classif icationSchemeTable> 






<CSAlias alias="ia" 






href="urn :tva :metadata 


cs 


IntendedAudienceCS:2 005"/> 


<CSAlias alias="co" 






href="urn: tva : metadata 


cs 


ContentCS:2005"/> 


<CSAlias alias="or" 






href =" urn : tva : metadata 


cs 


OriginationCS:2005"/> 


<CSAlias alias="in" 






href="urn : tva : metadata 


cs 


IntentionCS:2005"/> 


<CSAlias alias="at" 






href = "urn : tva : metadata 


cs 


AtmosphereCS:2 005"/> 


<CSAlias alias="ro" 






href =" urn : tva : metadata 


cs 


RoleCS:2001"/> 



£75/ 



69 ETSI TS 1 02 822-2 V1 .3.1 (2006-01 ) 



</Classif icationSchemeTable> 
<Us e r De script! on > 
<UserPreferences> 

<mpeg7 : FilteringAndSearchPref erences> 
<mpeg7 : CreationPref erences> 

<mpeg7 : Creator pref erenceValue=" 100 "> 
<mpeg7:Role href=" : ro : ACTOR"/> 
<mpeg7 : Agent xsi : type="mpeg7 : PersonType"> 
<mpeg7 : Name> 

<mpeg7 : GivenName>Sean</mpeg7 : GivenName> 
<mpeg7 :FamilyName>Connery</mpeg7 : FamilyName> 
</mpeg7 :Name> 
</mpeg7 :Agent> 
<mpeg7 : Character> 

<mpeg7 : GivenName> James Bond</mpeg7 : GivenName> 
</mpeg7 :Character> 
</mpeg7 : Creator> 

<mpeg7 : Creator pref erenceValue="30"> 
<mpeg7 : Role href =" : ro : DIRECTOR" /> 
<mpeg7 : Agent xsi : type="mpeg7 : PersonType"> 
<mpeg7 : Name> 

<mpeg7 : GivenName> John</mpeg7 : GivenName> 
<mpeg7 : FamilyName>Smith</mpeg7 : FamilyName> 
</mpeg7 :Name> 
</mpeg7 :Agent> 
</mpeg7 : Creator> 

<mpeg7 : Creator pref erenceValue="30"> 
<mpeg7 :Role href=" : ro : AUTHOR" /> 
<mpeg7 : Agent xsi : type="mpeg7 : PersonType"> 
<mpeg7 : Name> 

<mpeg7 : GivenName> Jane</mpeg7 : GivenName> 
<mpeg7 :FamilyName>Austen</mpeg7 :FamilyName> 
</mpeg7 :Name> 
</mpeg7 :Agent> 
</mpeg7 : Creator> 

<mpeg7 :Creator preferenceValue="50"> 
<mpeg7 :Role href=" : ro : BROADCASTER" /> 
<mpeg7 : Agent xsi : type="mpeg7 : Organ iz at ionType"> 

<mpeg7 :Name>BBC</mpeg7 : Name> 
</mpeg7 :Agent> 
</mpeg7 : Creator> 

<mpeg7 : Creator pref erenceValue=" 30 "> 
<mpeg7 :Role href=" : ro : BROADCASTER" /> 
<mpeg7 : Agent xsi : type="mpeg7 : OrganizationType"> 

<mpeg7 : Name>ITV</mpeg7 : Name> 
</mpeg7 :Agent> 
</mpeg7 : Creator> 

<mpeg7 : Creator pref erenceValue="30"> 
<mpeg7 :Role href=" : ro : BROADCASTER" /> 
<mpeg7 : Agent xsi : type="mpeg7 : OrganizationType"> 

<mpeg7 : Name>Sky</mpeg7 :Name> 
</mpeg7 :Agent> 
</mpeg7 : Creator> 

<mpeg7 : Creator pref erenceValue=" 60 "> 
<mpeg7:Role href=" : ro : ACTOR"/> 
<mpeg7 : Agent xsi : type="mpeg7 : PersonType"> 
<mpeg7 : Name> 

<mpeg7 : GivenName>Humphrey</mpeg7 : GivenName> 
<mpeg7 :FamilyName>Bogart</mpeg7 :FamilyName> 
</mpeg7 :Name> 
</mpeg7 :Agent> 
</mpeg7 : Creator> 

<mpeg7 : Creator pref erenceValue=" 60 "> 
<mpeg7:Role href=" : ro : ACTOR"/> 
<mpeg7 : Agent xsi : type="mpeg7 : PersonType"> 
<mpeg7 : Name> 

<mpeg7 : GivenName>Meg</mpeg7 : GivenName> 
<mpeg7 :FamilyName>Ryan</mpeg7 :FamilyName> 
</mpeg7 :Name> 
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</mpeg7 :Agent> 
</mpeg7 : Creator> 

<mpeg7 : Creator pref erenceValue=" 60 "> 
<mpeg7:Role href=" : ro : ACTOR"/> 
<mpeg7 : Agent xsi : type="mpeg7 : PersonType"> 
<mpeg7 : Name> 

<mpeg7 : GivenName>Clint</mpeg7 : GivenName> 
<mpeg7 :FamilyName>Eastwood</mpeg7 :FamilyName> 
</mpeg7 :Name> 
</mpeg7 :Agent> 
</mpeg7 : Creator> 

<mpeg7 : Creator pref erenceValue=" 60 "> 
<mpeg7:Role href=" : ro : ACTOR"/> 
<mpeg7 : Agent xsi : type="mpeg7 : PersonType"> 
<mpeg7 : Name> 

<mpeg7 : GivenName>Peter</mpeg7 : GivenName> 
<mpeg7 :FamilyName>Firth</mpeg7 :FamilyName> 
</mpeg7 :Name> 
</mpeg7 :Agent> 
</mpeg7 : Creator> 
</mpeg7 : Great ionPreferences> 
<mpeg7 :ClassificationPreferences> 

<mpeg7:Genre pref erenceValue="20" href=" : ia : 4 . 2 . 2 . 2"> 

<mpeg7 : Name > Age 2 5-34</mpeg7 : Name> 
</mpeg7 : Genre> 
<mpeg7:Genre pref erenceValue="20" href =" : co : 3 . 1 . 1"> 

<mpeg7 :Name>News</mpeg7 :Name> 
</mpeg7 : Genre> 
<mpeg7:Genre pref erenceValue="80" href=" : co : 3 . 2 . 1"> 

<mpeg7 : Name>Sports - Athletics</mpeg7 :Name> 
</mpeg7 : Genre> 
<mpeg7 : Genre pref erenceValue="80" href =" : co : 3 . 5 . 1"> 

<mpeg7 : Name>Amusement- Gameshows</mpeg7 :Name> 
</mpeg7 : Genre> 
<mpeg7:Genre pref erenceValue="80" href =" : or : 5 . 1"> 

<mpeg7 :Name>Studio</mpeg7 :Name> 
</mpeg7 : Genre> 
<mpeg7:Genre preferenceValue="20" href=" : in : 1 . 1"> 

<mpeg7 : Name>Entertainment</mpeg7 :Name> 
</mpeg7 : Genre> 
<mpeg7:Genre pref erenceValue="40" href =" : at : 8 . 1"> 

<mpeg7 : Name>Alternative</mpeg7 : Name> 
</mpeg7 : Genre> 
<mpeg7 : Genre pref erenceValue="40" href =" : at : 8 . 6"> 

<mpeg7 :Name>Breathtaking</mpeg7 :Name> 
</mpeg7 : Genre> 
<mpeg7 : Genre pref erenceValue="40" href =" : at : 8 . 30"> 

<mpeg7 : Name>Inspirational</mpeg7 : Name> 
</mpeg7 : Genre> 
</mpeg7 : Classif icationPref erences> 
</mpeg7 : FilteringAndSearchPref erences> 
</UserPref erences> 
</UserDescription> 
</TVAMain> 
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Table 3 is an example of programme classification to be associated with user profile data sets for each of the 
programmes. 

Table 3: Examples of programme classification for user profile data sets 



Title 


Pride and Prejudice 


Blue Moon 


News at Ten 


Goldfinger 


CONTENT 


3.4.14 Fiction/Drama, 


3.1.6.5 Non Fiction, 


3.1.1 Non Fiction, 


3.4.6.1 Fiction, 




Period Drama 


Sciences, 
Space/Universe 


News 


Action, Adventure 


ORIGINATION 


5.8 1 .3 TV, Made on 


5.8.1.3 TV, Made on 


5.8.2.1 TV, Studio, 


5.7 Cinema 




Location, Edited 


Location, Edited 


Live 


Originated 


INTENTION 


1.1 Entertain 


1.8 Enrich 


1 .2 Inform 


1.1 Entertain 


ATMOSPHERE 


8.24 Heart Rending, 


8.30 Inspirational, 


Null field 


8.20 Gripping 




8.25 Heartwarming 


8.15 Edifying, 




8.17 Fast moving 




8.39 Romantic 


8.4 Ambitious, 




8.22 Gutsy 




8.41 Sad, 


8.2 Analytical 




8.38 Rollercoaster 




8.48 Stunning 


8.48 Stunning 




8.44 Sexy 

8.45 Stunning 
8.51 Thriller 


INTENDED 


Age Groups, Adults, 


Social Group AB 4.4.1 


Age Group Adults 


Age Group, Age 


AUDIENCE 


4.2.2 


AB and CI C2 4.4.2, 


4.2.2 . 


14-15 4.2.1.3 and 




Geographical 


Geographical, Universal 


Geographical 4.7.5 


Adults 4.2.2 , 




Universal 4.7.1, 


4.7.1 


Local - (Keyword 


Gender Male 4.6.1, 




Language English (en) 


Language English (en) 


Sunnyvale) 
Language English 
(en) and Spanish 
(es) 


Geographical, 
Universal 4.7.1, 
Language English 
(en) 


BROADCASTER 


BBC 


NOS 


ITV 


Sky 


(from MPEG 7 










RoleCS) 










DIRECTOR 


John Smith 


Null field 


Null field 


Cubbi Broccoli 


(From MPEG7 










RoleCS) 










KEY TALENT 


Peter Firth 


Peter Firth 


Null Field 


Sean Connery 


(From TVA 










RoleCS) 










KEY CHARACTER 


Null Field 


Null Field 


Null Field 


James Bond 


(From TVA 










RoleCS) 










Author From 


Jane Austin 


Null field 


Null field 


Ian Fleming 


(MPEG7 RoleCS) 










(WRITER) 











When inbound content data enters the box, an agent in the box might use the previously captured data from viewed 
programmes to match. Using the above examples of data, the agent might assume that as two programmes had Peter 
Firth as a Key Talent the viewer would like to watch other programmes in which he takes part. If Atmosphere Stunning 
appears in three out of four programmes and would be high on the list to look out for. In the weighting environment the 
agent might automatically assign Stunning the maximum positive value. 

Data to be returned to the service provider or Broadcaster 

Providers of content wish to know how their content is performing as far as the consumer is concerned. Business 
decisions will be made as a result (e.g. cancel the scheduling of a programme because the viewers do not like it; not 
enough people are watching a particular strand; the viewer really likes astronomy documentaries but they are not 
providing any, advertisers will want to know viewers numbers, appreciation index across demographics etc.). 

The following information might be useful: 

1) Actual viewing of their own programmes by receiving a list of locators/CRIDs that refers to their own 
programmes only. 

2) An anonymous aggregated user profile consisting of a sub set of fields that will indicate the viewing habits of 
the viewing population across all content. 
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The first one is out of scope for Phase 1 because no authenticated return channel RMP has been specified: 

1) A subset of the data above could be returned to the broadcaster if this functionality has been enabled by the 
consumer or required by the consumer's contract with the service provider. A minimum useful set of data 
might include the following elements: 

Content, Origination, Intention, Atmosphere and Intended Audience. 

Each with the associated aggregated rating. This will enable service providers and broadcasters the ability to analyse 
aggregated viewer preferences and allows them to make business decisions based on their performance in these areas. 

Issues surrounding rating of data. 

MPEG7 define the rating scale between a minimum of -100 and a maximum of + 100 with a no preference value set at 0. 

To make systems interoperable and viewer preferences portable (e.g. when they buy a newer box or wish to take their 
profile to a remote location - on holiday, second home etc.) it is important that systems comply with this scale, i.e. there 
must be both positive and negative values which are 100 even if only a limited number of choices between these values 
are implemented. 



EXAMPLE: 



-100 -80 

or 

-100 

or 

-100 



-60 



-40 



-20 



-0 



20 



40 



60 



80 



-66 



-33 



33 



66 



50 



100 



100 



100 



50 

in the implementation in the box these can be labelled as implementers' wishes, etc. e.g.: 
12 3 4 



or 



really do not like do not Uke 



neutral 



quite like 



like a lot 



7.13 Phase 1 example: RMPI descriptive metadata 

7.13.1 Introduction 

This clause contains three examples of RMPI descriptive metadata for free-to-air (ETA), Pay-Per-View (PPV) and 
Video-On-Demand (VoD) content. These examples show only metadata expressing RMPI-MB (i.e. prior to domain 
acquisition). In order to obtain the corresponding RMPI-M (i.e. post domain acquisition), the RMPI type flag has to be 
changed, and the domain identifier and single point of control identifier (if applicable) have to be set. 

7. 1 3.2 Free-to-air content 

The following example shows a possible combination of rights granted to a given piece of content broadcast free-to-air: 

• Content is not scrambled and will remain unscrambled after domain acquisition. 

• No possibility is granted to acquire new rights. 

• In the receiving domain. Play, Analogue Export, Digital Export (both HD and SD) are granted. Proximity 
Control is the only restriction that applies. Required security level is the lowest. 

• The same rights are granted in any other domain. No Proximity Control applies but Geographic Control (only 
Germany) does. A medium security level is required to enforce that restriction. 
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<?xml version="l .0" encoding="UTF-8 " ?> 
<TVAMain xmlns="urn:tva: metadata: 2 005" 

xmlns : tva2="urn : tva : metadata : extended : 2005" 

xmlns : tva="urn : tva : metadata : 2005" 

xmlns : rmpi="urn : tva : rmpi : 2 005 " 

xmlns :mpeg21="urn : tva :mpeg21 : 2 005" xmlns :mpeg7="urn : tva :mpeg7 : 2005" 

xmlns : xsi="http : //www . w3 . org/2 001/XMLSchema-instance" 

xsi : schemaLocation="urn : tva : metadata :extended:2005 tva2_metadata_3-3_vlll . xsd" 

xsi : tYpe="tva2 :ExtendedTVAMainType"> 

<tva2 :RMPITable xml : lang="en-us"> 

<tva2 :RMPIDescription RMPIDescriptionId="String"> 
<rmpi : AncillaryRMPI> 

<rmpi:RMPITypeFlag>RMPI-MB</rmpi:RMPITYpeFlag> 
<rmpi : VersionOfRMPI>0</rmpi : VersionOf RMPI> 
<rmpi : OriginOfRMPI>FTABroadcasterDE</rmpi : OriginOfRMPI> 
<rmpi : Cipher href ="urn : rmpi : cs : CipherCS : 2005 : 0"> 
<tva:Name xml : lang="en-us">no cipher</tva :Name> 
<tva : Definition xml : lang="en-us">no cipher</tva : Def inition> 
</rmpi : Cipher> 

<rmpi :MBScramblingControl>maintain</rmpi :MBScramblingControl> 
</rmpi : AncillaryRMPI> 
<rmpi : ExtendRights> 

<rmpi : ExtendRightsFlagNotGranted>not granted</rmpi : ExtendRightsFlagNotGranted> 
</rmpi : ExtendRights> 
<rmpi : ReceivingDomainRights> 

<rmpi : PlayRightFlag>granted</rmpi : PlayRightFlag> 
<rmpi : AnalogueExportRight> 
<rmpi : Anal ogueExport Right FlagGr ante d> grant ed</ rmpi : Anal ogueExport Right FlagGr ant ed> 
</rmpi : AnalogueExportRight> 
<rmpi :DigitalExportSDRight> 
<rmpi : DigitalExportRightFlagGranted>granted</rmpi : DigitalExportRightFlagGranted> 
</rmpi :DigitalExportSDRight> 
<rmpi : DigitalExportHDRight> 
<rmpi : DigitalExportRightFlagGranted>granted</rmpi : D i gi t a lExpo r t Right FlagGr an ted> 
</rmpi : DigitalExportHDRight> 

<rmpi : SecurityLevel>level 0</rmpi : SecurityLevel> 
<rmpi : GeographicalControl>Any</rmpi : GeographicalControl> 
<rmpi : PhysicalProximityFlag>controlled</rmpi : PhysicalProximityFlag> 
</rmpi : ReceivingDomainRights> 
<rmpi : AnyDomainRights> 

<rmpi : PlayRightFlag>granted</rmpi : PlayRightFlag> 
<rmpi : AnalogueExportRight> 
<rmpi : Anal ogueExport Right FlagGr ante d> grant ed</ rmpi : Anal ogueExport Right FlagGr ant ed> 
</rmpi : AnalogueExportRight> 
<rmpi :DigitalExportSDRight> 
<rmpi : DigitalExportRightFlagGranted>granted</rmpi : DigitalExportRightFlagGranted> 
</rmpi : DigitalExportSDRight> 
<rmpi : DigitalExportHDRight> 
<rmpi : DigitalExportRightFlagGranted>granted</rmpi : D i gi t a lExpo r t Right FlagGr an ted> 
</rmpi : DigitalExportHDRight> 

<rmpi : SecurityLevel>level l</rmpi : SecurityLevel> 
<rmpi : GeographicalControl>GermanY</rmpi : GeographicalControl> 
</rmpi : AnyDomainRights> 
</tva2 :RMPIDescription> 
</tva2 :RMPITable> 
</TVAMain> 
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7.13.3 Pay-per-view content 



The following example shows a possible combination of rights granted to a given piece of content broadcast e.g. by a 
Pay-TV operator, where: 

• Content has to be re-scrambled using AES when acquired in the domain. 

• Possibility to acquire new rights is granted. The Pay-TV operator will grant these rights. 

• In the receiving domain, Play Right is granted with ability to trick play the content. Content can be exported to 
analogue or digital (both HD and SD) outputs but only for immediate viewing. A high security level is 
required. 

• No rights are granted to other domains. 

<?xml version="l .0" encoding="UTF-8 " ?> 
<?xml version="l .0" encoding="UTF-8 " ?> 
<TVAMain xmlns="urn : tva : metadata : 2 005 " 

xmlns : tva2="urn : tva : metadata : extended : 2005" 

xmlns : tva="urn : tva : metadata : 2005" 

xmlns : rmpi="urn : tva : rmpi : 2 005" 

xmlns :mpeg21="urn : tva :mpeg21 : 2 005 " xmlns :mpeg7="urn : tva :mpeg7 : 2005" 

xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 

xsi : schemaLocation="urn : tva : metadata :extended:2005 tva2_metadata_3-3_vlll . xsd" 

xsi : type="tva2 :ExtendedTVAMainTYpe"> 

<tva2 :RMPITable xml : lang="en-us"> 

<tva2 :RMPIDescription RMPIDescriptionId="String"> 
<rmpi : AncillarYRMPI> 

<rmpi :RMPITypeFlag>RMPI-MB</rmpi : RMPITYpeFlag> 
<rmpi : VersionOfRMPI>0</rmpi : VersionOf RMPI> 
<rmpi : OriginOfRMPI>FTABroadcasterDE</rmpi : OriginOf RMPI> 
<rmpi : Cipher href ="urn : rmpi : cs : Cipher CS : 2005 : 0"> 
<tva:Name xml : lang="en-us">no cipher</tva :Name> 
<tva : Definition xml : lang="en-us">no cipher</tva :Def inition> 
</rmpi : Cipher> 

<rmpi :MBScramblingControl>maintain</rmpi :MBScramblingControl> 
</rmpi : AncillaryRMPI> 
<rmpi : ExtendRights> 

<rmpi : ExtendRightsFlagNotGranted>not granted</rmpi : ExtendRightsFlagNotGranted> 
</rmpi : ExtendRights> 
<rmpi : ReceivingDomainRights> 

<rmpi : PlaYRightFlag>granted</rmpi : PlayRightFlag> 
<rmpi : AnalogueExportRight> 
<rmpi : Anal ogueExport Right FlagGr ante d> grant ed</ rmpi : Anal ogueExport Right FlagGr ant ed> 
</rmpi : AnalogueExportRight> 
<rmpi : DigitalExportSDRight> 
<rmpi : DigitalExportRightFlagGranted>granted</rmpi : D i gi t a lExpo r t Right FlagGr an ted> 
</rmpi : DigitalExportSDRight> 
<rmpi : DigitalExportHDRight> 
<rmpi : DigitalExportRightFlagGranted>granted</rmpi : DigitalExportRightFlagGranted> 
</rmpi : DigitalExportHDRight> 

<rmpi : SecuritYLevel>level 0</rmpi : SecuritYLevel> 
<rmpi : GeographicalControl>AnY</rmpi : GeographicalControl> 
<rmpi : PhYsicalProximitYFlag>controlled</rmpi : PhYsicalProximitYFlag> 
</rmpi : ReceivingDomainRights> 
<rmpi : AnYDomainRights> 

<rmpi : PlaYRightFlag>granted</rmpi : PlaYRightFlag> 
<rmpi : AnalogueExportRight> 
<rmpi : Anal ogueExport Right FlagGr ante d> grant ed</ rmpi : Anal ogueExport Right FlagGr ant ed> 
</rmpi : AnalogueExportRight> 
<rmpi : DigitalExportSDRight> 
<rmpi : DigitalExportRightFlagGranted>granted</rmpi : DigitalExportRightFlagGranted> 
</rmpi :DigitalExportSDRight> 
<rmpi : DigitalExportHDRight> 
<rmpi : DigitalExportRightFlagGranted>granted</rmpi : DigitalExportRightFlagGranted> 
</rmpi : DigitalExportHDRight> 

<rmpi : SecuritYLevel>level l</rmpi : SecuritYLevel> 
<rmpi : GeographicalControl>GermanY</rmpi : GeographicalControl> 
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</rmpi : AnyDomainRights> 
</tva2 :RMPIDescription> 
</tva2 :RMPITable> 
</TVAMain> 



7.13.4 Video-On-Demand Content 

The following example shows a possible combination of rights granted to a given piece of content provided by a content 
provider using DRM technology, where: 

• Content is scrambled using Camellia and needs not to be re-scrambled when acquired in the domain. 

• Possibility to acquire new rights is granted. An URL is given for that purpose. 

• In the receiving domain, Play Right is granted for two days. Only one copy of the content can be made within 
these two days and this copy is usable by one single device. Content can be exported only to HD digital output 
and only for immediate viewing. Content can only be redistributed in the proximity of the receiving domain 
and within Japan. The highest security level is required. 

• No rights are granted to other domains. 

<?xml version="l .0" encoding="UTF-8 " ?> 
<TVAMain xmlns="urn : tva : metadata : 2 005 " 

xmlns : tva2="urn : tva : metadata : extended : 2005" 

xmlns : tva="urn : tva : metadata : 2005" 

xmlns : rmpi="urn : tva : rmpi : 2 005" 

xmlns :mpeg21="urn : tva :mpeg21 : 2 005 " xmlns :mpeg7="urn : tva :mpeg7 : 2005" 

xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 

xsi : schemaLocation="urn : tva : metadata :extended:2005 tva2_metadata_3-3_vlll . xsd" 

xsi : type="tva2 :ExtendedTVAMainType"> 

<tva2 :RMPITable xml : lang="en-us"> 

<tva2 :RMPIDescription RMPIDescriptionId="String"> 
<rmpi : AncillarYRMPI> 

<rmpi :RMPITypeFlag>RMPI-MB</rmpi : RMPITYpeFlag> 
<rmpi:VersionOfRMPI>0</rmpi:VersionOfRMPI> 
<rmpi : OriginOfRMPI>FTABroadcasterDE</rmpi : OriginOf RMPI> 
<rmpi : Cipher href ="urn : rmpi : cs : Cipher CS : 2005 : 0"> 
<tva:Name xml : lang="en-us">no cipher</tva :Name> 
<tva : Definition xml : lang="en-us">no cipher</tva : Def inition> 
</rmpi : Cipher> 

<rmpi :MBScramblingControl>maintain</rmpi :MBScramblingControl> 
</rmpi : AncillaryRMPI> 
<rmpi : ExtendRights> 

<rmpi : ExtendRightsFlagNotGranted>not granted</rmpi : ExtendRightsFlagNotGranted> 
</rmpi : ExtendRights> 
<rmpi : ReceivingDomainRights> 

<rmpi : PlayRightFlag>granted</rmpi : PlayRightFlag> 
<rmpi : AnalogueExportRight> 
<rmpi : Anal ogueExport Right FlagGr ante d> grant ed</ rmpi : Anal ogueExport Right FlagGr ant ed> 
</rmpi : AnalogueExportRight> 
<rmpi : DigitalExportSDRight> 
<rmpi : DigitalExportRightFlagGranted>granted</rmpi : D i gi t a lExpo r t Right FlagGr an ted> 
</rmpi : DigitalExportSDRight> 
<rmpi : DigitalExportHDRight> 
<rmpi : DigitalExportRightFlagGranted>granted</rmpi : DigitalExportRightFlagGranted> 
</rmpi : DigitalExportHDRight> 

<rmpi : SecurityLevel>level 0</rmpi : SecurityLevel> 
<rmpi : GeographicalControl>Any</rmpi : GeographicalControl> 
<rmpi : PhYsicalProximitYFlag>controlled</rmpi : PhysicalProximityFlag> 
</rmpi : ReceivingDomainRights> 
<rmpi : AnyDomainRights> 

<rmpi : PlayRightFlag>granted</rmpi : PlayRightFlag> 
<rmpi : AnalogueExportRight> 
<rmpi : Anal ogueExport Right FlagGr ante d> grant ed</ rmpi : Anal ogueExport Right FlagGr ant ed> 
</rmpi : AnalogueExportRight> 
<rmpi : DigitalExportSDRight> 
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<rmpi : DigitalExportRightFlagGranted>granted</rmpi : DigitalExportRightFlagGranted> 
</rmpi :DigitalExportSDRight> 
<rmpi : DigitalExportHDRight> 
<rmpi : DigitalExportRightFlagGranted>granted</rmpi : DigitalExportRightFlagGranted> 
</rmpi : DigitalExpor 
tHDRight> 

<rmpi : SecurityLevel>level l</rmpi : SecurityLevel> 
<rmpi : GeographicalControl>GermanY</rmpi : GeographicalControl> 
</rmpi : AnyDomainRights> 
</tva2 :RMPIDescription> 
</tva2 :RMPITable> 
</TVAMain> 



8 RMPI cookbook examples and scenarios 

8.1 Introduction 

The following illustrates how the TVA-RMPI specification (TS 102 822-5-1 [7]) may be used as a standalone 
specification or may be integrated with other technologies to enable key business scenarios. These examples are not 
exhaustive and do not cover all combinations of RMPI field settings. It is anticipated that there will be many other 
business models that are not illustrated and will require other combinations of RMPI field settings. 



8.2 RMP system dependencies 



"RMP systems" are defined as those systems which recognize and enforce RMPI grants. It is understood that for RMPI 
to be effectively used within RMP systems that compliance bodies must establish specific rules for associated functions 
and components. 

8.3 RMP concepts 

8.3.1 Copy control versus playback control 

RMPI regulates the use of governed content, but does not regulate its movement. In a digital era, the movement of 
content files is difficult to constrain. However, the use of such files can be managed using trusted systems, including 
cryptographic techniques and DRM technologies. By managing the use of protected content files, the legacy copy 
control models can be replicated in a digital environment. 

8.3.2 Targeting content consumption and usage with RMPI 

Usage control is expressed in terms of RMP domains. An RMP domain is defined as a set of TVA-RMP compliant 
devices that are securely bound to each other for the purpose of exchanging protected content. It is left to the 
compliance bodies that adopt TVA-RMP specifications to refine this definition in terms of their specific requirements. 

TVA-RMPI distinguishes rights issued to all the domains that originally receive the broadcast transmission of content 
("Receiving Domain") from rights granted to RMP -compliant domains that may subsequently receive the same content 
from other than the original source ("Any Domain"). 

According to the RMPI settings, the use of content can be limited to those domains that received the original broadcast. 
RMPI settings can also enable the usage of shared content between RMP compliant domains. 

Rights can be dynamically updated in all of the above cases through the use of "Extend Rights". "Extend Rights" is used 
by RMP devices to request the delivery of rights to specific uniquely identified domains. 
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8.3.3 "Export Rights" as distinct from "Play Rigint" 

The "Play Right" is Hmited to rendering on a TVA-RMP compUant device only. Rendering on non-RMP compliant 
devices (e.g. a legacy display) requires the transfer of content usage from the TVA-RMP device to the non-RMP device 
and this right is not included in the semantic of "Play Right". 

The transfer of content usage from TVA-RMP to non-RMP systems is addressed through the use of export rights 
("Analogue Export Right", "HD Digital Export Right", "SD Digital Export Right"). Conditions on these rights can be 
applied to permit the rendering of content which achieves the same effect as "do not redistribute" in a broadcast 
environment. 

RMPI includes information to regulate the release of governed content to systems that do not recognize RMPI. The 
specification of these rights is handled through the export rights. 

8.3.4 RMP / non-RMP interoperability 

The purpose of granting the export right is to permit interoperability with non-RMP compliant systems. If the export 
right is not granted, then the release of content from an RMP compliant system is prohibited. For example, a "Play 
Right" granted without any export right would permit rendering of content only by an RMP compliant display device. 
Alternatively an "Analogue Export Right" would permit content to be delivered to a legacy playback device. 



8.4 Lifecycle of RMPI 



RMPI can exist in two successive phases; RMPl-MB and RMPI-M. RMPI-MB is transmitted in conjunction with the 
broadcast signal. At the time of reception in the end user's TVA-RMP Domain it is converted to RMPI-M. Rights that 
are granted to the Receiving Domain and Single Point of Control (if present) in RMPI-MB are carried over in RMPI-M. 
Generic references to the Receiving Domain and Single Point of Control (if present) in RMPI-MB are translated into 
specific references through the explicit statement of Identifiers in RMPI-M. In order to maintain the persistence of the 
rights assigned by the broadcaster or content provider, a TVA-RMP compliant receiver shall not change any other value 
in RMPI. Rights granted to Any Domain are always carried over unchanged from RMPI-MB to RMPI-M. 



8.5 Compliance 



Implementations of TV-Anytime RMP specifications are anticipated to take place under compliance regimes that will 
enforce the implementation of a given scenario to meet the needs of a respective product space, market segment or other 
defined environment. 

Compliance bodies may also manage certification and revocation infrastructure, and otherwise administer services to 
vendors of approved implementations of standards-based solutions. 

Compliance bodies also define, amongst other things, rules of operation, robustness, approved device behaviours, 
applicable trademark and logo licensing, and the certification and registration of trusted entities approved as compliant. 
While in principle compliance issues may be handled by individual implementers, it is anticipated that compliance will 
in general be provided by entities offering compliance certification operating on a regional or market-specific basis. 

It is left to the compliance body to establish what constitutes an RMP device. For example, an analogue display device 
within a chassis of a digital PDR might still be considered an RMP device according to a given compliance regime. 

8.6 Scenarios 

8.6.1 Scenario 1 : Free-To-Air broadcast with no redistribution/viewing 
control 

Intent 

Free-To-Air content is broadcast over the air with no usage constraints. 
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The Free-To-Air content with the grant below is allowed to migrate without farther redress from the broadcaster and 
can be consumed anywhere. It can be exported out of the trusted platform. The content could equally have been 
delivered initially over the Internet. 

Table 4: Grant carried in RIVIPI-IVIB for scenario 1 



Function 


Semantic | Value 


Grant to: 


"Receiving Domain" - can be single device or more. 


Right 


Play: play_right_flag 


1 


Export 


Analogue Export: analogue export right flag 


1 


Digital SD Export: digital export SD flag 


1 


Digital HD Export: digital export HD flag 


1 


Constraints 


Geographic Control: 


Not asserted 


N/A 


Single point of control: 


Not asserted 





Simultaneous Rendering Count 


Not asserted 





Physical Proximity: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Grant to: 


"Any Domain" - can be single device or more 


Right 


Play 


1 


Export 


Analogue Export 


1 


Digital SD Export 


1 


Digital HD Export 


1 


Constraints 


Geographic Control: 


Not asserted 


N/A 


Single Point of Control: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


Not asserted 


N/A 


Single Point of Control 


Not asserted 


N/A 


Ancillary applies to both grants 


Ancillary 


Cipher Algorithm 


No cipher 


0x0 


Scrambling control: 


IVIaintain Original 





Version of RIVIPI 


Compliance Tag 


15 bits 


Origin of RIVIPI: 


Broadcaster ID 


128 bits 


RMPI-Type flag 


RMPI-MB 





Extend Rights Apply to both grants 


Extend Rights 


Extend Right Granted 


Not Granted 





Security Level 


As per compliance 


00 


Source of Additional Rights 


Not Granted 


Null 



The RMPI-M grant is the same except for two fields, namely: 

• Domain Id will carry the identifier of the Receiving Domain. 

• RMPI-Type flag will be 1 (i.e. RMPI-M). 
Comments 

The export rights are granted to address legacy devices e.g. digital/analogue displays that are not RMP compliant. 

"Extend Rights" is not granted since all rights have already been granted. 

The grant to the Receiving Domain could be omitted in both RMPI-MB and RMPI-M since the business model makes 
no distinction between Receiving Domain and Any Domain. 
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The scrambling control is set to "maintain original scrambling" meaning that the TVA-RMP receiver does not perform 
any scrambling or descrambling operation upon acquisition. The cipher field is set to "no cipher" because the content 
was not originally scrambled and has been maintained in this state. 

8.6.2 Scenario 2: Free-To-Air broadcast witinout autinorized redistribution 
over tlie Internet 

Intent 

Free-To- Air content is broadcast over air with redistribution constraints. Content is not authorized to be redistributed by 
the user over the Internet. Content can be freely redistributed within the home environment. 

This is the same as Scenario 1, but with the audience constrained to the receiver base at the time of broadcast. That is, 
content copying between target audience members or between target/non target audience members is not allowed, 
though personal storage onto external removal media is permitted. In such a case, the removable copy is not bound to 
the domain in which it was created. 

Table 5: Grants carried in RIUIPI-IUIB for scenario 2 



Function 


Semantic Value 


Grant to: 


"Receiving Domain" - can be single device or more. 


Right 


Play: play_right_flag 


1 


Export 


Analogue Export: analogue export right flag 


1 


Digital SD Export: digital export SD flag 


1 


Digital HD Export: digital export HD flag 


1 


Constraints 


Geographic Control: 


Not asserted 


N/A 


Single point of control: 


Not asserted 





Simultaneous Rendering Count 


Not asserted 





Physical Proximity: 


Asserted 


1 


Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Device /media bound + 

immediate viewing through Ext 

CP 


10 


HD Digital Export Control: 


Device /media bound + 

immediate viewing through Ext 

CP 


10 


Analogue Export Signalling: 


Not asserted 





Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


Not asserted 


N/A 


Single Point of Control 


Not asserted 


N/A 


Grant to: 


"Any Domain" - can be single device or more 


Riglit 


Play 





Export 


Analogue Export 





Digital SD Export 





Digital HD Export 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single Point of Control: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Ancillary applies to both grants 


Ancillary 


Cipher Algorithm 


No cipher 


0x0 


Scrambling control: 


Maintain Original 





Version of RIVIPI 


Compliance Tag 


15 bits 


Origin of RIVIPI: 


Broadcaster ID 


128 bits 


RMPI-Type flag 


RMPI-MB 
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Function Semantic 




Value 


Extend Rights Apply to both grants 


Extend Rights 


Extend Right Granted 


Not Granted 





Security Level 


As per compliance 


00 


Source of Additional Rights 


Not Granted 


Null 



The RMPI-M grant is the same except for two fields, namely: 

• Domain Id will carry the identifier of the Receiving Domain. 

• RMPI-Type flag will be 1 (i.e. RMPI-M). 
Comments 

Since redistribution over the Internet is not permitted, no rights are granted to Any Domain. 

In order to support legacy usage models such as copy to a VHS or a DVD-R, export rights are granted. However, in the 
case of digital export, the following constraint has been applied: 'export condition asserted, bound to device or media, 
includes immediate viewing. Hand-ojf to compliance body certified non-RMP content protection systems only is 
permitted. This means that export can only take place to non-RMP content protection systems that prevent 
redistribution over the Internet as approved by the compliance body. 

The RMPI-MB described in the scenario is functionally equivalent to the ATSC redistribution control descriptor 
(broadcast flag). 



8.6.3 



Intent 



Scenario 3: Free-To-Air broadcast with content consumption 
constrained to a geograpliical area 



Free-To-Air content is broadcast over air with geographical constraints: Content is not authorized to be consumed 
outside a given geographical area. 

Table 6: Grants carried in RIUIPI-IUIB for scenario 3 



Function 


Semantic Value 


Grant to: 


"Receiving Domain" - can be single device or more. 


Right 


Play: play_right_flag 


1 


Export 


Analogue Export: analogue export right flag 


1 


Digital SD Export: digital export SD flag 


1 


Digital HD Export: digital export HD flag 


1 


Constraints 


Geographic Control: 


Asserted 


UK 


Single point of control: 


Not asserted 





Simultaneous Rendering Count 


Not asserted 





Physical Proximity: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Device /media bound + 

immediate viewing through Ext 

CP 


10 


HD Digital Export Control: 


Device /media bound + 

immediate viewing through Ext 

CP 


10 


Analogue Export Signalling: 


Not asserted 





Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


Not asserted 


N/A 


Single Point of Control 


Not asserted 


N/A 
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Function 


Semantic Value 


Grant to: 


"Receiving Domain" - can be single device or more. 


Right 


Play: play_right_flag 


1 


Export 


Analogue Export: analogue export right flag 


1 


Digital SD Export: digital export SD flag 


1 


Digital HD Export: digital export HD flag 


1 


Constraints 


Geographic Control: 


Asserted 


UK 


Single point of control: 


Not asserted 





Simultaneous Rendering Count 


Not asserted 





Physical Proximity: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Device /media bound + 

immediate viewing through Ext 

CP 


10 


HD Digital Export Control: 


Device /media bound + 

immediate viewing through Ext 

CP 


10 


Analogue Export Signalling: 


Not asserted 





Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


Not asserted 


N/A 


Single Point of Control 


Not asserted 


N/A 


Grant to: 


"Any Domain" - can be single device or more 


Right 


Play 


1 


Export 


Analogue Export 


1 


Digital SD Export 


1 


Digital HD Export 


1 


Constraints 


Geographic Control: 


Asserted 


UK 


Single Point of Control: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Device /media bound + 

immediate viewing through Ext 

CP 


10 


HD Digital Export Control: 


Device /media bound + 

immediate viewing through Ext 

CP 


10 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Ancillary applies to both grants 


Ancillary 


Cipher Algorithm 


No cipher 


0x0 


Scrambling control: 


IVIaintain Original 





Version of RIVIPI 


Compliance Tag 


15 bits 


Origin of RIVIPI: 


Broadcaster ID 


128 bits 


RMPI-Type flag 


RMPI-MB 





Extend Rights Apply to both grants 


Extend Rights 


Extend Right Granted 


Not Granted 





Security Level 


As per compliance 


00 


Source of Additional Rights 


Not Granted 


Null 



The RMPI-M grant is the same except for two fields, namely: 

• Domain Id will carry the identifier of the Receiving Domain. 

• RMPI-Type flag will be 1 (i.e. RMPI-M). 
Comments 

The compliance body has specified territories, e.g. "UK", for geographical control purposes. 

The grant to the Receiving Domain could be omitted in both RMPI-MB and RMPI-M since the business model makes 
no distinction between Receiving Domain and Any Domain. 
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In order to support legacy usage models such as copy to a VHS or a DVD-R, export rights are granted. In the case of 
digital export, the following constraint has been applied: 'export condition asserted, bound to device or media, includes 
immediate viewing. Hand-off to compliance body certified non-RMP content protection systems only is permitted' . This 
means that export can occur only to non-RMP compliant content protection systems that cannot be used to circumvent 
the geographical restriction as approved by the compliance body. If a content protection system has not the latter 
property, content restricted to a geographical area may not be exported to that content protection system. 

8.6.4 Scenario 4: Free-To-Air content witin viewing and redistribution 
controls 

Intent 

This scenario explores the time limited control of broadcast content. 



Table 7: Grants carried in RIVIPI-IVIB for scenario 4 



Function 


Semantic Value 


Grant to: 


"Receiving Domain"- can be single device or more. 


Right 


Play: play_right_flag 


1 


Export 


Analogue Export: analogue export right flag 


1 


Digital SD Export: digital export SD flag 


1 


Digital HD Export: digital export HD flag 


1 


Constraints 


Geographic Control: 


Not asserted 


N/A 


Single point of control: 


Not asserted 





Simultaneous Rendering Count 


Not asserted 





Physical Proximity: 


Not asserted 





Buffer Duration: 


Not asserted 


GO 


Time Window Start/End: 


Start:March2004 


0x01 D1 


End: 10 days later 


0x01 DB 


SD Digital Export Control: 


Immediate Viewing 


11 


HD Digital Export Control: 


Immediate Viewing 


11 


Analogue Export Signalling: 


Immediate Viewing 


10 


Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


Not asserted 


N/A 


Single Point of Control 


Not asserted 


N/A 


Grant to: 


"Any Domain" - can be single device or more 


Right 


Play 


1 


Export 


Analogue Export 


1 


Digital SD Export 


1 


Digital HD Export 


1 


Constraints 


Geographic Control: 


Not asserted 


N/A 


Single Point of Control: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start:March2004 


0x01 D1 


End: 10 days later 


0x01 DB 


SD Digital Export Control: 


Immediate Viewing 


11 


HD Digital Export Control: 


Immediate Viewing 


11 


Analogue Export Signalling: 


Immediate Viewing 


10 


Analogue SD Control: 


Not asserted 





Ancillary applies to both grants 


Ancillary 


Cipher Algorithm 


No cipher 


0x0 


Scrambling control: 


Maintain Original 





Version of RIVIPI 


Compliance Tag 


15 bits 


Origin of RIVIPI: 


Broadcaster ID 


128 bits 


RMPI-Type flag 


RMPI-MB 





Extend Rights Apply to both grants 


Extend Rights 


Extend Right Granted 


Granted 


1 


Security Level 


As per compliance 


00 


Source of Additional Rights 


Broadcast Broker 


RIVIPI. com 
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The RMPI-M grant is the same except for two fields, namely: 

• Domain Id will carry the identifier of the Receiving Domain. 

• RMPI-Type flag will be 1 (i.e. RMPI-M). 
Comments 

Export only permitted through external copy protection system for immediate viewing purposes. 

"Extend Rights" is granted to allow the user to extend the content viewing window. 

The grant to the Receiving Domain could be omitted in both RMPI-MB and RMPI-M since the business model makes 
no distinction between Receiving Domain and Any Domain. 

8.6.5 Scenario 5: Free-To-Air broadcast witinout support for legacy 
receivers 

Intent 

This scenario assumes a wide use of RMPI. There is no need to support legacy devices and therefore there is no need to 
grant export rights. 

Table 8: Grants carried in RIVIPI-IVIB for scenario 5 



Function 


Semantic Value 


Grant to: 


"Receiving Domain" - can be single device or more. 


Right 


Play: play_right_flag 


1 


Export 


Analogue Export: analogue export right flag 





Digital SD Export: digital export SD flag 





Digital HD Export: digital export HD flag 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single point of control: 


Not asserted 





Simultaneous Rendering Count 


Not asserted 





Physical Proximity: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


Not asserted 


N/A 


Single Point of Control 


Not asserted 


N/A 


Grant to: 


"Any Domain" - can be single device or more 


Right 


Play 


1 


Export 


Analogue Export 





Digital SD Export 





Digital HD Export 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single Point of Control: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 
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Function 


Semantic Value 


Grant to: 


"Receiving Domain" - can be single device or more. 


Right 


Play: play_right_flag 


1 


Export 


Analogue Export: analogue export right flag 





Digital SD Export: digital export SD flag 





Digital HD Export: digital export HD flag 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single point of control: 


Not asserted 





Simultaneous Rendering Count 


Not asserted 





Physical Proximity: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


Not asserted 


N/A 


Single Point of Control 


Not asserted 


N/A 


Grant to: 


"Any Domain" - can be single device or more 


Right 


Play 


1 


Export 


Analogue Export 





Digital SD Export 





Digital HD Export 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single Point of Control: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Ancillary applies to both grants 


Ancillary 


Cipher Algorithm 


No cipher 


0x0 


Scrambling control: 


Maintain Original 





Version of RMPI 


Compliance Tag 


15 bits 


Origin of RMPI: 


Broadcaster ID 


128 bits 


RMPI-Type flag 


RMPI-MB 





Extend Rights Apply to both grants 


Extend Rights 


Extend Right Granted 


Not granted 





Security Level 


As per compliance 


00 


Source of Additional Rights 


Not granted 


Null 



The RMPI-M grant is the same except for two fields, namely: 

• Domain Id will carry the identifier of the Receiving Domain. 

• RMPI-Type flag will be 1 (i.e. RMPI-M). 
Comments 

"Extend Rights" is not granted since the only new right the user may be granted is an export right. 

The grant to the Receiving Domain could be omitted in both RMPI-MB and RMPI-M since the business model makes 
no distinction between Receiving Domain and Any Domain. 

8.6.6 Scenario 6: Free-To-Air live streaming 

Intent 

Public service content is streamed in the clear over the Internet for immediate viewing only. This is currently the 
situation for some public service radio services. 
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Table 9: Grants carried in RiVIPI-iVIB for scenario 6 



Function 


Semantic Value 


Grant to: 


"Receiving Domain" - can be single device or more. 


Right 


Play: play_right_flag 


1 


Export 


Analogue Export: analogue export right flag 





Digital SD Export: digital export SD flag 





Digital HD Export: digital export HD flag 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single point of control: 


Not asserted 





Simultaneous Rendering Count 


Not asserted 





Physical Proximity: 


Asserted 


1 


Buffer Duration: 


Immediate Viewing 


10 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


Not asserted 


N/A 


Single Point of Control 


Not asserted 


N/A 


Grant to: 


"Any Domain" - can be single device or more 


Right 


Play 





Export 


Analogue Export 





Digital SD Export 





Digital HD Export 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single Point of Control: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Ancillary applies to both grants 


Ancillary 


Cipher Algorithm 


No cipher 


0x0 


Scrambling control: 


IVIaintain Original 





Version of RIVIPI 


Compliance Tag 


15 bits 


Origin of RMPI: 


Broadcaster ID 


128 bits 


RMPI-Type flag 


RMPI-MB 





Extend Rights Ap 


ply to both grants 


Extend Rights 


Extend Right Granted 


Not Granted 





Security Level 


As per compliance 


00 


Source of Additional Rights 


Null (not granted) 


Null 



The RMPI-M grant is the same except for two fields, namely: 

• Domain Id will carry the identifier of the Receiving Domain. 

• RMPI-Type flag will be 1 (i.e. RMPI-M). 

Comments 

Since content is meant only for immediate viewing, there is no need to grant rights to domains other than the receiving 
one. 

The proximity control is aimed at preventing live redistribution via Wide Area Networks. 
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8.6.7 Scenario 7: Scrambled Free-To-Air 

Intent 

Scrambled Free-To- Air content is broadcast carrying RMPI-MB. If the user has registered, the receiver hands over 
content to the user's private domain. Content is descrambled in the receiver. 

This model is similar to the Japanese Free-To-Air broadcast where content is scrambled for transmission. 

Table 10: Grants carried in RIUIPI-IVIB for scenario 7 



Function 


Semantic | Value 


Grant to: 


"Receiving Domain" - can be single device or more. 


Right 


Play: play_right_flag 


1 


Export 


Analogue Export: analogue export right flag 


1 


Digital SD Export: digital export SD flag 


1 


Digital HD Export: digital export HD flag 


1 


Constraints 


Geographic Control: 


Not asserted 


N/A 


Single point of control: 


Not asserted 





Simultaneous Rendering Count 


Not asserted 





Physical Proximity: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Device /media bound + 

immediate viewing through Ext 

CP 


10 


HD Digital Export Control: 


Device /media bound + 

immediate viewing through Ext 

CP 


10 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


Not asserted 


N/A 


Single Point of Control 


Not asserted 


N/A 


Grant to: 


"Any Domain" - can be single device or more 


Right 


Play 





Export 


Analogue Export 





Digital SD Export 





Digital HD Export 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single Point of Control: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Ancillary applies to both grants 


Ancillary 


Cipher Algorithm 


No cipher 


0x0 


Scrambling control: 


Change scrambling 


1 


Version of RIVIPI 


Compliance Tag 


15 bits 


Origin of RMPI: 


Broadcaster ID 


128 bits 


RMPI-Type flag 


RMPI-MB 





Extend Rights Apply to both grants 


Extend Rights 


Extend Right Granted 


Not Granted 





Security Level 


As per compliance 


00 


Source of Additional Rights 


Null (not granted) 


Null 



The RMPI-M grant is the same except for two fields, namely: 

• Domain Id will carry the identifier of the Receiving Domain. 

• RMPI-Type flag will be 1 (i.e. RMPI-M). 
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Comments 

The scrambling control is set to "change scrambling" so that content is descrambled in the receiver. The receiver knows 
which scrambling algorithm was originally used (e.g. M2 or Camellia). Since the cipher field is set to "no cipher" , the 
receiver will not re-scramble the content but hand it over in the clear to the TVA-RMP system. 

"Digital Export" is granted but only to copy protection systems authorized by the compliance body. The external copy 
protection system will apply the "immediate viewing" or "bound to device/media" restriction. 

No rights are granted to Any Domain so as to prevent unauthorized redistribution, which is the primary reason why the 
content was scrambled over transmission. 

8.6.8 Scenario 8: Pay-TV subscription witin limited number of 
simultaneous consumptions 

Intent 

Content is broadcast under the control of a CA system and the pay-TV receiver manages the handover of control to the 
TV-Anytime RMP system in order to enable persistent content protection in the Receiving Domain. 

The contract between the pay-TV provider and the subscriber which is enforced through the CA system stipulates that 
simultaneous rendering of the services is limited to a certain number (2 in this example) of rendering devices. The RMP 
system is used to enforce this rule in the Receiving Domain. 

Table 11 : Grants carried in RIVIPI-IVIB for scenario 8 



Function 


Semantic Value 


Grant to: 


"Receiving Domain" - can be single device or more. 


Right 


Play: play_right_flag 


1 


Export 


Analogue Export: analogue export right flag 


1 


Digital SD Export: digital export SD flag 


1 


Digital HD Export: digital export HD flag 


1 


Constraints 


Geographic Control: 


Not asserted 


N/A 


Single point of control: 


Asserted 


1 


Simultaneous Rendering Count 


Asserted 


2 


Physical Proximity: 


Asserted 


1 


Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: 01 June 2005 


0x0205 


End: 30 June 2005 


0x0222 


SD Digital Export Control: 


Asserted: immediate viewing 


11 


HD Digital Export Control: 


Asserted: immediate viewing 


11 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


Not asserted 


N/A 


Single Point of Control 


Not asserted 


N/A 


Grant to: 


"Any Domain" - can be single device or more 


Right 


Play 





Export 


Analogue Export 





Digital SD Export 





Digital HD Export 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single Point of Control: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 
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Function 


Semantic Value 


Grant to: 


"Receiving Domain" - can be single device or more. 


Right 


Play: play_right_flag 


1 


Export 


Analogue Export: analogue export right flag 


1 


Digital SD Export: digital export SD flag 


1 


Digital HD Export: digital export HD flag 


1 


Constraints 


Geographic Control: 


Not asserted 


N/A 


Single point of control: 


Asserted 


1 


Simultaneous Rendering Count 


Asserted 


2 


Physical Proximity: 


Asserted 


1 


Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: 01 June 2005 


0x0205 


End: 30 June 2005 


0x0222 


SD Digital Export Control: 


Asserted: immediate viewing 


11 


HD Digital Export Control: 


Asserted: immediate viewing 


11 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


Not asserted 


N/A 


Single Point of Control 


Not asserted 


N/A 


Grant to: 


"Any Domain" - can be single device or more 


Right 


Play 





Export 


Analogue Export 





Digital SD Export 





Digital HD Export 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single Point of Control: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Ancillary applies to both grants 


Ancillary 


Cipher Algorithm 


AES 


0x1 


Scrambling control: 


Change scrambling 


1 


Version of RMPI 


Compliance Tag 


15 bits 


Origin of RMPI: 


Broadcaster ID 


128 bits 


RMPI-Type flag 


RMPI-MB 





Extend Rights Apply to both grants 


Extend Rights 


Extend Right Granted 


Not Granted 





Security Level 


As per compliance 


00 


Source of Additional Rights 


Null (not granted) 


Null 



The RMPI-M grant is the same except for three fields, namely: 

• Domain Id will carry the identifier of the Receiving Domain. 

• RMPI-Type flag will be 1 (i.e. RMPI-M). 

• Single Point of Control Id will carry the identifier of the device that is the Single Point of Control. 

Comments 

This example assumes that the CA system uses RMPI-MB to convey rights to the domain. In practice, this may not 
happen since those rights might be carried in proprietary CA messages. Therefore, in such a case, there would be no 
RMPI-MB. 

Since the initial acquisition of the content is governed by a CA system, rights are only granted to the Receiving 
Domain. 

"Analogue Export" is granted to address legacy analogue displays. The Analogue_Export_Signalling condition is not 
asserted in order to enable export of the content to VHS tapes. 
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"SD Digital Export" and "HD Digital Export" are granted to address digital displays that are not TVA-RMP compliant. 
The SD and HD digital export controls are set to "export condition asserted, immediate viewing only. Hand-ojf to 
compliance body certified non-RMP content protection system only is permitted" . This is to ensure that no further 
copies of the content are made when digital export occurs. 

"Single Point of Control" is asserted to enable simultaneous rendering count. The simultaneous rendering count 
condition is set to "2". This is to ensure persistence of the incoming CA usage rules in the Receiving Domain. 

"Proximity Control" is asserted because the pay-TV contract does not allow content retransmission over a 
Wide-Area-Network. 

The "Time Window" is asserted so that the grant is only valid for the period of entitlement as expressed by the CA. 
Since the time window is asserted, the buffer duration condition is not asserted. 

The scrambling control bit is set to "7" to indicate that the broadcast scrambling has to be replaced by the cipher as 
specified by the cipher field. 

8.6.9 Scenario 9: Push Content 

Intent 

Content is pushed to the Receiving Domain without any rendering rights ("Play", "Analogue Export", "HD Digital 
Export", "SD Digital Export") in a speculative manner by the service provider. "Extend Rights" is granted so that the 
user can acquire those rendering rights on an individual basis. 

When the user wishes to view the content, the Extent Rights right is exercised. The RMP subsystem in the PDR 
contacts the source of additional rights (the CA system) so that the transaction to acquire the new rights is performed 
via the device user interface. 

In the background, the CA system authorizes the user and generates new grants expressed in a new instance of 
RMPI-M. 

Table 12: Grants carried in RIVIPI-IUIB for scenario 9 



Function 


Semantic Value 


Grant to: 


"Receiving Domain" - can be single device or more. 


Right 


Play: play_right_flag 





Export 


Analogue Export: analogue export right flag 





Digital SD Export: digital export SD flag 





Digital HD Export: digital export HD flag 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single point of control: 


Not asserted 





Simultaneous Rendering Count 


Not asserted 





Physical Proximity: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


Not asserted 


N/A 


Single Point of Control 


Not asserted 


N/A 
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Function 


Semantic Value 


Grant to: 


"Receiving Domain" - can be single device or more. 


Right 


Play: play_right_flag 





Export 


Analogue Export: analogue export right flag 





Digital SD Export: digital export SD flag 





Digital HD Export: digital export HD flag 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single point of control: 


Not asserted 





Simultaneous Rendering Count 


Not asserted 





Physical Proximity: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


Not asserted 


N/A 


Single Point of Control 


Not asserted 


N/A 


Grant to: 


"Any Domain" - can be single device or more 


Right 


Play 





Export 


Analogue Export 





Digital SD Export 





Digital HD Export 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single Point of Control: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Ancillary applies to both grants 


Ancillary 


Cipher Algorithm 


DVB CSA 2 


0x4 


Scrambling control: 


Change scrambling 





Version of RMPI 


Compliance Tag 


15 bits 


Origin of RMPI: 


Broadcaster ID 


128 bits 


RMPI-Type flag 


RMPI-MB 





Extend Rights Apply to both grants 


Extend Rights 


Extend Right Granted 


Granted 


1 


Security Level 


As per compliance 


00 


Source of Additional Rights 


CA System Id 


CA A 



The RMPI-M grant depends on the rights purchased by the user. 

Comments 

No rights are originally granted for the Receiving Domain and for Any Domain. 

The user has to exercise the "Extend Rights" right to consume the content. 
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8.6.1 Scenario 1 0: Pay-Per-View Content, "buy to l^eep" 

Intent 

Content is delivered under control of a CA system as part of a pay-per-view service. The user purchases the right to 
keep the content without time restriction for consumption within his private domain. 

Control of the content is handed over from the CA system to the TVA-RMP system by the pay television receiver. 

Table 13: Grants carried in RIUIPI-IUI for scenario 10 



Function 


Semantic | Value 


Grant to: 


"Receiving Domain" - Domain ID specified. 


Right 


Play: play_right_flag 


1 


Export 


Analogue Export: analogue export right flag 


1 


Digital SD Export: digital export SD flag 


1 


Digital HD Export: digital export HD flag 


1 


Constraints 


Geographic Control: 


Not asserted 


N/A 


Single point of control: 


Not asserted 





Simultaneous Rendering Count 


Not asserted 





Physical Proximity: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Asserted: immediate viewing 


11 


HD Digital Export Control: 


Asserted: immediate viewing 


11 


Analogue Export Signalling: 


Asserted: immediate viewing 


10 


Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


User domain Id 


MyDomain 


Single Point of Control 


Not asserted 


N/A 


Grant to: 


"Any Domain" - can be single device or more 


Right 


Play 





Export 


Analogue Export 





Digital SD Export 





Digital HD Export 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single Point of Control: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Ancillary applies to both grants 


Ancillary 


Cipher Algorithm 


AES 


0x1 


Scrambling control: 


Change scrambling 


1 


Version of RIVIPI 


Compliance Tag 


15 bits 


Origin of RMPI: 


Broadcaster ID 


128 bits 


RMPI-Type flag 


RMPI-M 


1 


Extend Rights Apply to both grants 


Extend Rights 


Extend Right Granted 


Not Granted 





Security Level 


As per compliance 


00 


Source of Additional Rights 


Null (not granted) 


Null 



Comments 

There is no RMPI-MB because the CA generates RMPI-M locally. 

There is no grant for Any Domain because the business model requires the content to be viewable in only the Receiving 
Domain. 
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"HD Digital Export", "SD Digital Export" and "Analogue Export" are granted to support legacy displays that are not 
TVA-RMP capable. Since the business model requires consumption within the domain, export is restricted to 
immediate viewing. 

The "Time Window" condition is not asserted because rights are granted to the user's private domain without time 
restriction to enable the buy-to-keep business model. 

8.6.1 1 Scenario 1 1 : Import of copy protected analogue content 

Intent 

An analogue program is fed to a TVA-RMP compliant FDR with associated copy-control signals (e.g. CGMS-A). The 
associated copy control rule indicates "copy-once". The TVA-RMP compliant device generates RMPI-M from the 
incoming copy control information as per the compliance rules defined by the compliance body. 

Table 14: Grants carried in RIVIPI-IVI for scenario 11 



Function 


Semantic | Value 


Grant to: 


"Receiving Domain" - Domain ID specified. 


Right 


Play: play_right_flag 


1 


Export 


Analogue Export: analogue export right flag 


1 


Digital SD Export: digital export SD flag 


1 


Digital HD Export: digital export HD flag 


1 


Constraints 


Geographic Control: 


Not asserted 


N/A 


Single point of control: 


Not asserted 





Simultaneous Rendering Count 


Not asserted 





Physical Proximity: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Asserted: immediate viewing 


11 


HD Digital Export Control: 


Asserted: immediate viewing 


11 


Analogue Export Signalling: 


Asserted: immediate viewing 


10 


Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


User domain Id 


MyDomain 


Single Point of Control 


Not asserted 


N/A 


Grant to: 


"Any Domain" - can be single device or more 


Right: 


Play 





Export 


Analogue Export 





Digital SD Export 





Digital HD Export 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single Point of Control: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Ancillary applies to both grants 


Ancillary 


Cipher Algorithm 


AES 


0x1 


Scrambling control: 


Change scrambling 


1 


Version of RIVIPI 


Compliance Tag 


15 bits 


Origin of RMPI: 


Broadcaster ID 


128 bits 


RMPI-Type flag 


RMPI-M 


1 


Extend Rights Apply to both grants 


Extend Rights 


Extend Right Granted 


Not Granted 





Security Level 


As per compliance 


00 


Source of Additional Rights 


Null (not granted) 


Null 
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Comments 

There is no RMPI-MB because the TVA-RMP system in the PDR generates RMPI-M from the incoming analogue copy 
control information. 

There is no grant for Any Domain because CGMS-copy once is asserted in the incoming analogue copy control 
information, meaning that content is not for redistribution. 

"HD Digital Export", "SD Digital Export" and "Analogue Export" are granted to support legacy displays that are not 
TVA-RMP capable. Since the business model requires consumption within the domain and no further copy, export is 
restricted to "immediate viewing". 

Content is scrambled using AES as this is the default RMP scrambling algorithm. 

8.6.12 Scenario 12: Video on Demand 

Intent 

Content is purchased by the user from a Video On Demand service. Content is protected by a proprietary DRM system 
between the VOD server and the TVA-RMP compliant PDR. Control of the content is then handed over to the 
TVA-RMP system to address TVA-RMP enabled displays. The VOD business model dictates that no recording rights 
other than transient ones are granted. 

Table 15: Grants carried in RIVIPI-IVI for scenario 12 



Function 


Semantic Value 


Grant to: 


"Receiving Domain" - Domain ID specified. 


Right 


Play: play_right_flag 


1 


Export 


Analogue Export: analogue export right flag 





Digital SD Export: digital export SD flag 





Digital HD Export: digital export HD flag 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single point of control: 


Asserted 


1 


Simultaneous Rendering Count 


Asserted 


1 


Physical Proximity: 


Asserted 


1 


Buffer Duration: 


Asserted 


10 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


User domain Id 


IVIyDomain 


Single Point of Control 


PDR Id 


IVIyPDR 


Grant to: 


"Any Domain" - can be single device or more 


Riglit 


Play 





Export 


Analogue Export 





Digital SD Export 





Digital HD Export 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single Point of Control: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 
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Function 


Semantic 


Value 


Grant to: 


"Receiving Domain" - Domain ID specified. 


Right 


Play: play_right_flag 


1 


Export 


Analogue Export: analogue export right flag 





Digital SD Export: digital export SD flag 





Digital HD Export: digital export HD flag 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single point of control: 


Asserted 


1 


Simultaneous Rendering Count 


Asserted 


1 


Physical Proximity: 


Asserted 


1 


Buffer Duration: 


Asserted 


10 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Identifiers 


Domain 


User domain Id 


IVIyDomain 


Single Point of Control 


PDRId 


IVIyPDR 


Grant to: 


"Any Domain" - can be single device or more 


Riglit 


Play 





Export 


Analogue Export 





Digital SD Export 





Digital HD Export 





Constraints 


Geographic Control: 


Not asserted 


N/A 


Single Point of Control: 


Not asserted 





Buffer Duration: 


Not asserted 


00 


Time Window Start/End: 


Start: Not asserted 


0x0000 


End: Not asserted 


OxFFFF 


SD Digital Export Control: 


Not asserted 


00 


HD Digital Export Control: 


Not asserted 


00 


Analogue Export Signalling: 


Not asserted 


00 


Analogue SD Control: 


Not asserted 





Ancillary applies to both grants 


Ancillary 


Cipher Algorithm 


Camellia 


0x2 


Scrambling control: 


IVIaintain scrambling 





Version of RIVIPI 


Compliance Tag 


15 bits 


Origin of RIVIPI: 


Broadcaster ID 


128 bits 


RMPI-Type flag 


RMPI-IVI 


1 


Extend Rights App 


y to both grants 




Extend Rights 


Extend Right Granted 


Not Granted 





Security Level 


As per compliance 


00 


Source of Additional Rights 


Null (not granted) 


Null 



Comments 

There is no RMPI-MB because the DRM system generates RMPI-M locally. 

There is no grant for Any Domain because the business model requires the content to be viewable in only the Receiving 
Domain. 

"HD Digital Export", "SD Digital Export" and "Analogue Export" are not granted because the VOD service provider 
requires that the content is available only on TVA-RMP enabled displays and not on legacy displays. The user is made 
aware of this restriction at the time of signing up to the service. 

The single point of control condition is asserted and the simultaneous rendering count is set to "1" so that the service is 
only available to one display. The FDR is the single point of control device, whilst only one RMP compliant rendering 
device (the display) can display the content. 

The proximity control is asserted to limit viewing to the home where content is acquired in the first place. 

Buffer duration is set to "condition set, no buffer". This is to prevent unauthorized permanent recordings of the VOD 
content on the PDR. Trick play is enabled on the remote VOD server outside TVA-RMP as part of the VOD service. 
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Issues per process 



This clause gives some explicit implementation hints for less obvious issues in the different TV-Anytime processes, 
i.e. publish, search, select/locate, acquire, view and finish. 



9.1 General system issues 



To get an actual TV-Anytime system into the processes described in the previous clauses some generic system issues 
need to be solved. These issues are out of the scope of TV-Anytime, but some of them are presented here to ease the 
implementer's life. Most issues are related to actual PDR implementations. The issues fit into a number of categories 
discussed below. 



9.1 .1 Set-up and service discovery 



In the set-up process of a PDR, e.g. when the user first installs a box in his home, a number of things need to be done to 
allow for it to find the TV-Anytime metadata and location resolution services. The way that this works is transport 
dependent and no complete descriptions for all transports are given, the analogue case and the digital DVB satellite case 
are discussed below. 

Analogue environment 

For content resolution to work in an analogue environment a mapping between a content reference ID and a physical 
channel frequency, date and time or duration needs to be made. This information can be carried via IP in the VBI, for 
example, or via a smart card or floppy disc. In the VBI case the box only needs a well know port number to do service 
discovery. After the location of the resolution tables and resolution authority records are known, download of those can 
commence. Metadata is probably too bulky to be carried in the VBI, so other means of getting that into the box need to 
be there, e.g. a telephone line. 

For the analogue situation a preferred way of issuing locators would be, for example: 

analog:cablenetworkXYZ/broadcaster/8ani/lhour. 

This would allow the broadcaster to use the same locators across multiple cable networks since frequency allocations 
will be different. For this to work the box needs to be able to make the mapping between channel name and physical 
channel frequency. This can be done during set-up by the user or, for example, in a Western-European PAL 
environment by looking at VBI information carrying Programme Delivery Control (PDC) for analogue VCRs. The 
same trick would also be useful in a digital environment with broadcasters being on a number of different media like 
satellite, cable etc. 

Similarly for metadata, the box needs to be able to find out where metadata is carried. This could be done via the VBI, 
e.g. using Teletext or PDC. 

Digital DVB environment 

In the DVB environment, operation is similar but for the actual locators that are put into the location resolution tables. 
In the DVB environment service information, program IDs, event triggers and start-stop times could, for example, be 
used. To get the location resolution authority records, the box needs to know where to look in the transport stream. 

One solution could be that there is a well-known service, e.g. "TV-Anytime services" in the transport containing pointers 
to all data needed by the box, e.g. it would point to the location of location resolution authority records and actual 
location resolution tables. 

Another possibility is that each broadcast service contains its own "TV-Anytime services" entry pointing at the relevant 
tables. 

In the DVB environment containers should be reserved, e.g. tables or sections that could carry the pointer to the TVA 
metadata. The current TVA specifications do not cater for this. 

DVB has specified how to carry TV-Anytime data over DVB networks in TS 102 323 "Carriage and Signalling of 
TV-Anytime Information in DVB Transport Streams" [20]. 
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9.1.2 Language Identification 



The xml:lang is extensively used for the identification of languages. It is important to note that the identification 
capabilities of the "language" datatype are now based on RFC 3066 [21], which enables the identification of a wider 
range of languages than the earlier RFC 1766. ISO's 3 character language codes may now be used. The earlier 
extensibility mechanism remains in place for languages not included in ISO 639 [22]. 

9.1 .3 Transport and delivery of TV-Anytime data 

The transport and delivery of TVA data requires the definition and specification of a set of technical features currently 
not covered by the TV-Anytime specification. These features can be summarized as follows: 

• Identification and signalling: an identification mechanism (e.g. a metadata location descriptor corresponding 
to a specific metadata format) is needed to associate specific resources to the transport of TVA data, and to 
signal that data being transported is, for example, TVA data. Signalling can also be used to inform the system 
about the presence of incoming TVA data. 



• 



Location: a mechanism (e.g. a RAR or a metadata locator) that allows to point at the actual location of the data 
container from which location resolution data or metadata will be retrieved. The definition of a locator needs 
to take into account the transitory nature of the associated information. 

It should allow identifying, signalling and locating TVA data carried over a variety of transport systems 
(e.g. MPEG TS - over the PES, a data or object carousel, in metadata section, or over IP). 

RSS or Atom feeds are now becoming the most common content syndication standards. Podcasting, an automated 
approach for delivering audio file to a personal playback device using RSS feeds, has caused a great deal of excitement 
lately. In the near future, it can also be applied for Video or interactive multimedia applications delivery. 

Similarly, RSS information feed technology can be repurposed for TV-Anytime metadata delivery. 

There are two ways of adopting RSS as TV-Anytime metadata distribution, direct encoding of TV-Anytime metadata 
within the RSS feed and only using RSS for the notification of newly created or changed events on TV-Anytime 
metadata distribution servers. By including TV-Anytime metadata directly in the feed, they can be filtered to find the 
most relevant content of interest. 

The core specifications of the major version of RSS standards provide module-based extensibility for anyone who 
wants to add new elements or features. To extend elements in RSS format enabling carriage of TV-Anytime metadata, a 
new module corresponding to TVA metadata elements needs to be created. Elements in the module should be specified 
only if there is no suitable alternative already in RSS "Standard" or "Proposed" modules. Those modules reflecting the 
TV-Anytime metadata model would be expected to be developed by implementers for TV-Anytime compliant content 
management or distribution systems. 



9.1 .4 Updating resolution tables 



Both the RAR tables and the Resolution tables need to be kept up to date. The RARs contain information about the 
various resolution services available to the PDR device. The Resolution tables contain the mappings of CRIDs to other 
CRIDs or to locators. In the broadcast scenario, these tables must be pushed to the box, most likely using a broadcast 
carousel. Whole tables should be sent regularly to provide for new PDRs entering the system, but incremental updates 
are also useful, as they save bandwidth and also (probably) require less processing power at the client device when they 
are received. 

Changes in the version field of the RAR (made by the location resolution provider) indicate to the client an update of all 
RARs for a given authority serviced by this provider. The expiry date of a RAR is an additional trigger for updates. The 
updating of location resolution tables is tied to the transport mechanism. 

Below is an example of updating RARs where a resolution provider has several resolution services available in the 
same box. In the example, the broadcaster HBC has three channels on the multiplex (HBCl, HBC2 and HBC Gold, 
which are available on dvb://1.2eef 3f5, dvb://1.2eef.l06 and dvb://1.2eef.3f5, respectively). A fourth channel is 
provided by another broadcaster who is also a resolution provider (broadcaster.co.jp). This channel is available at 
dvb://1.104.e5f. 
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The PDR has four RARs stored, three of which point to resolution services provided by HBC, and the other RAR that 
points to the resolution service of the other broadcaster. 





RAR A 


RARB 


RARC 


RARD 


RAR fields 










Authority 


hbc.com 


creator.com 


creator.com 


creator.com 


Resolution Provider 


hbc.com 


hbc.com 


hbc.com 


broacaster.co.jp 


URL 


dvb://1 .2eef.3f5 


dvb://1.2eef.106 


dvb://1 .2eef.3f5 


dvb://1.104.e5f 


Version 


24 


2 


2 


96 



RAR A refers to CRIDs created by the broadcaster hbc.com who is also a resolution provider for hbc.com CRIDs. 
RAR B, RAR C and RAR D all refer to resolving CRIDs created by the creator.com CRID authority. 

If the PDR receives a RAR which contains: 



Authority 


creator.com 


Resolution Provider 


hbc.com 


URL 


dvb://1 .2eef.3f6 


Version 


3 



the PDR will discard all the RARs that have authority equal to creator.com and provider equal to hbc.com. In this 
example, the RAR above would cause RAR B and RAR C to be discarded and the new RAR to be stored in the PDR. 





RAR A 


RARD 


RARE 


RAR fields 








Authority 


hbc.com 


creator.com 


creator.com 


Resolution Provider 


hbc.com 


broacaster.co.jp 


hbc.com 


URL 


dvb://1 .2eef.3f5 


dvb://1.104.e5f 


dvb://1 .2eef.3f6 


Version 


24 


96 


3 



If the resolution provider wanted to update RAR B and keep RAR C as it is, they will need to transmit new versions of 
both RARs. 





RAR A 


RARD 


RARE 


RARF 


RAR fields 










Authority 


hbc.com 


creator.com 


creator.com 


creator.com 


Resolution Provider 


hbc.com 


broacaster.co.jp 


hbc.com 


hbc.com 


URL 


dvb://1 .2eef.3f5 


dvb://1.104.e5f 


dvb://1 .2eef.3f6 


dvb://1.2eef.3f5 


Version 


24 


96 


3 


3 



9.1.5 Updating metadata 

There is no mechanism defined that allow for update of part or all of the metadata. 

9.2 "Publish" process 

Re-run/repeat of content 

A re-run is defined as content that is broadcast at different times to suit user convenience, sometime subsequent to its 
original broadcast. A repeat is generally regarded as old content. The content creator may package content being 
re-shown within a short period of the original broadcast as a repeat, and leave the associated metadata untouched. If it is 
some months or years later, the content creator may package it as a re-run and alter the associated metadata. The 
consumer may regard it as original viewing, as a re-run or as a repeat of the same content. Regarding the creation and 
publication of a CRID to reference the re-run/repeat, a number of scenarios can be envisaged; 
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1) The original CRID may be re-used, but with a new locator. Also, alternative space and time locations may be 
provided for the content after resolution. The PDR can take advantage of multiple location options to resolve 
recording conflicts. The use of the same CRID, if the content creator always uses unique CRIDs, is also a way 
for the box to identify the item as having been previously consumed. If there is additional metadata available 
for this particular airing, instance metadata can be used. 

2) The content creator may issue a new CRID to refer to the re-run/repeat. From the PDRs perspective at least, 
the content is then regarded as different. The content creator may package the programme with new metadata, 
for example, if a motion picture actor dies, then her films may be re-run, the fact that she has died being added 
to the metadata surrounding the movie. 

3) A third party may issue a group CRID to refer to all airings of an item across many different service providers. 
This has the advantage that the local storage management can use the group CRID to help solve recording 
conflicts. From the consumer's perspective, each occurrence is effectively a repeat even though they occur 
across service providers. 

4) Instance Metadata Identifier. 

For the case when a broadcast is to be repeated (or re-run) using the same CRID, the metadata provider may wish to 
differentiate between these publication instances using the instance description metadata. This differentiation can be 
communicated to the viewer through EPG-like rendering on screen or utilized by a software agent acting on the viewer's 
behalf. 

When allocating Instance Metadata Identifiers to the instance descriptions, the metadata providers can choose to use an 
Instance Metadata identifier from its own proprietary namespace. As such the <name> field of the Instance Metadata 
Identifier must be included and arrangements made to supply these Instance Metadata Identifiers to collaborating 
resolution providers. 

Alternatively, the Instance Metadata Identifiers may be supplied by the CRID authority and used within the metadata 
without the <name> field of the Instance Metadata Identifier syntax. Resolution providers may also have access to these 
Instance Metadata Identifiers from the CRID authority and are able to supply the corresponding Instance Metadata 
Identifiers for each of the locators within the CRID location resolution table. 

Note that it is always possible for a location resolution provider to provide CRID location resolution tables for the 
CRID without any Instance Metadata Identifiers. 

9.3 "Search and select" processes 

Selection on basis of time/channel 

"What's on at 8 o'clock tonight?" 

The scenario depends on a few implementation issues (bullets 1 and 2) and/or how service providers will provide 
required metadata (bullets 3 and 4): 

1) With a location resolution service that, when given a CRID, only provides locators, the box would have to 
resolve all CRIDs and search for all 8 o'clock entries. 

2) If the box has access to the stored location resolution tables this is a straightforward query. 

3) The service provider could issue a (group) CRID containing all the contents available at a given time. This is a 
limited solution, similar to a restricted EPG. 

4) If the timing information is sent separately in the metadata stream (e.g. using instance metadata), there may be 
conflicts between the metadata and the location resolution data. 

Note that content that is already recorded is available at any time. 

Essentially the same content has different CRIDs 

"I want to get the "Foxes" comedy show". 
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The same content, at least in the eyes of the consumer, can have different CRIDs, because different service providers 
might decide to do so. Three options arise to deal with this using metadata, third parties or unique identification, 
respectively: 

1) A metadata search will return with multiple choices, with different CRIDs. The choice between them would 
depend on the available metadata. For example, the title field in the ProgramlnformationTable could be used to 
conduct such a search. Without a connection between the CRIDs of the content items grouping would have to 
be done in the box. 

2) A metadata aggregator could generate a (group) CRID, which refers to all of the different CRIDs. This creates 
a single point reference for the content. 

3) If the same content could be identified uniquely, the different offerings may be tied together in the box. Such a 
unique identifier could be carried in the Otherldentifier field in the ProgramlnformationTable. 

How to find a specific episode 

"I want to see episode 15 of the original "Foxes" series". 

1) This is straightforward, if the index attribute in the programme description data contains the episode number. 

2) The programme description data (e.g. title or synopsis) could contain the appropriate descriptive text for a 
textual search. Inconsistencies in phrases used may limit the use of a textual search. 

3) If the (group) CRID returns an ordered list of CRIDs one could infer the episode number. This is a limited 
solution and is not currently part of the content referencing specification. 

How to identify the latest episode of Foxes 

"I want the latest episode of "Foxes". 

This scenario can be implemented in the following ways: 

1) A service provider generates a CRID, which points to the latest episode within a service. 

2) A third-party generates a CRID, which points to the latest episode on all services. 

3) Choosing a (group) CRID will lead to the capture of the next available episode. 
Have I seen this content before? 

"I do not want to record this if I have seen it before". 

A box may store what the user has seen. If the box stores the CRID of the programme and all CRIDs were unique for all 
time, this would be sufficient. However, different service providers will use different CRIDs for the same content. Also 
service providers may issue a new CRID if the content has been changed only slightly or they want to promote the 
programme in a particular way. The system may need to store programme description data in order to fulfil this 
requirement. Alternatively, if a unique identifier is available in the Otherldentifier field, this could be used for this 
purpose. 

9.4 "Locate" process 

"Make locator names unambiguous" 

For example two satellites feed one box. In this scenario how does the system distinguish between say channel 5 from 
each satellite? 

Or, phrased differently, what happens when the same service is on both physical inputs? 

1) Box implementation issue. If the content on both feeds has the same CRIDs, the box can decide to listen to 
whichever feed based on some criteria (e.g. random "flip-a-coin criteria") or the PublicationType element in 
the user preferences DS can be used. 

2) If CRIDs are different between the two feeds, which implies the content to be different (differences in quality, 
encoding type,). The user will be the one deciding which one to listen to. 
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"Re-resolution" 



Currently there is no best practice defined for re-resolving locations. The only way to make sure that a PDR does not 
miss scheduling changes is to check back with the resolution tables every time they are updated. This drives the 
requirements for carriage of the data, e.g. frequency of re-transmission of location resolution data in the broadcast 
environment. Proper practice is to monitor the location resolution data, not the instance metadata. 

"Locate instance at a specific location" 

Using the Instance Metadata Identifier it is possible to select an instance at a specific location for capture. To determine 
the correct locator, the CRID together with the Instance Metadata Identifier should be used. 

9.5 "Acquire" process 

Acquisition of metadata with content and/or separate from content 

Some metadata may be related to the actual timeline of the content, e.g. metadata that needs to show up at a certain 
point in the programme. Currently there is no way of synchronizing (Meta) data with content in the TV-Anytime context. 

Validation of content 

On validation of the acquired content the following points are identified: 

• Trustworthiness of the resolving authority may be assumed. 

• It is impossible to attach the CRID used for resolving the content in all cases. 

• Other means of identification may be needed (e.g. V-IS AN, ISAN, Broadcaster own ID, etc.). 

• However, it also is impossible to attach a globally registered ID in all cases. 

Validation is possible if all "leaf" CRIDs are attached to the content, which is easily achievable when only working in 
an environment involving a single service provider. 

Programme Delivery Control, signalling resolution updates 

The resolution engine may inform the recording management unit of the latest updates in the delivery timing of the 
content (see clause 8.1.3). Alternatively the recording manager may poll the resolution engine. Recording management 
is an implementation issue and hence beyond the scope of the present document. However, service providers and box 
implementers are required to provide an accurate mechanism to update changes in the schedules similar to PDC. 

It is suggested that more accurate timing may be achieved by using "triggers" or other equivalent mechanisms in the 
transport stream e.g. DVB event ID. "Triggers" can be part of locator syntax. It is noted that Triggers will be transport 
dependent, e.g. DVB, ATSC, and ARIB. 

RMPI (TS 102 822-5-1 [7]) is not expected to be used as a unique tool. Compliance bodies will define other 
information to be used in conjunction with RMPI to make up license information. This information may include but is 
not limited to a content identifier, commercial information, cryptographic and security-related information. License 
information may include several RMPI instances with different associated commercial conditions. 



1 Phase 2 cookbook examples and scenarios 
1 0.1 Phase 2 example: New content types 

Several content types are covered as part of the examples given in the following clauses. 
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10.2 Phase 2 example: Packaging 
1 0.2.1 Program with an associated package 

The instance document describes a sports program with an associated package which includes an interactive 
appHcation. The package table provides information (in the example: middleware and audio) that can be used to 
determine which components of the package need to be captured. 

<?xml version="l .0" encoding="UTF-8 " ?> 
<TVAMain xmlns="urn:tva: metadata: 2 005" 

xmlns : tva2="urn : tva : metadata : extended : 2005" 

xmlns :mpeg21="urn : tva :mpeg21 : 2 005" xmlns :mpeg7="urn : tva :mpeg7 : 2005" 

xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 

xsi : schemaLocation="urn : tva : metadata : extended: 2 005 tva2_metadata_3-3_vlll . xsd" 

xsi :tYpe="tva2 :ExtendedTVAMainTYpe"> 

<ProgramDescription> 

<P rogramin format ionTable> 

< I -k -k -h -k -k ^ -k ^ -k ^ -h ^ -k ^ -k ^ -k ^ -k ^ -k ^ -k -k -k ^ -k -k -k ^ -k -k -k ^ -k -k -k ^ -k -k -k ^ -k -k -k ^ -k -k -k ^ -k -k > 

< ! -- Example of a Program having an associated Package --> 

<; I -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k > 

<ProgramInf ormation pr ogr ami d=" GRID : //f oo . com/WorldCupSoccer "> 
<BasicDescription> 

<Title>Football World Cup 2003</Title> 
<RelatedMaterial> 
<HowRelated 
href ="urn : tva : HowRelatedCS : AssociatedPackage" /> 
<MediaLocator> 

<mpeg7 :MediaUri>CRID : //foo . com/Package/ 12-1- 
2005</mpeg7 :MediaUri> 
</MediaLocator> 
</RelatedMaterial> 
</BasicDescription> 
< /P rogramin format ion> 

<; I -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k > 

<! — Attractor information for the Package associated --> 
<! — with the above Content --> 

<; I -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k -k -k k -k k -k k -k k > 

<ProgramInf ormation pr ogr ami d=" GRID : //f oo . com/Package/ 12-1-2005 "> 

<BasicDe script ion xsi : type="tva2 : ExtendedContentDescriptionType"> 
<Title>SportsActive</Title> 
<RelatedMaterial> 
<HowRelated 
href ="urn : tva : howrelatedCS : PackageMainContent " /> 
<MediaLocator> 
<mpeg7 :MediaUri> 
GRID : //f oo . com/WorldGupSoccer</mpeg7 :MediaUri> 
</MediaLocator> 
</RelatedMaterial> 
<tva2 : ContentProperties> 

<tva2 : Content Type href = "urn : tva : Content TypeCS : Package" /> 
</tva2 : ContentProperties> 
</BasicDescription> 
< /P rogramin format ion> 
</ProgramInf ormationTable> 
</ProgramDescription> 

<; I -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k > 

< ! -- Package Decision tree — > 

<; I -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k k -k -k -k k -k -k -k k -k k -k k > 

<tva2 : PackageTable> 

<tva2 :Package crid="CRID: //f oo . com/Package/12-l-2005"> 
<tva2 : Item> 

<tva2 :Choice choice_id="MIDDLEWARE_Choice" minSelections="0" 
maxSelections=" 1 "> 

<tva2 : Selection select_id="OPENTV"> 
<tva2 :Descriptor> 

<tva2 :0b jectDescription> 

<tva2 : ContentDescription> 
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<tva2 : Targetinginf ormation> 

<tva2 : Terminalinf ormation> 

< ! -- Add Middleware info here — > 
</tva2 : Terminalinf ormation> 
</tva2 : Targetinginf ormation> 
</tva2 : Con tent Description> 
</tva2:0bjectDescription> 
</tva2 :Descriptor> 
</tva2 : Selection> 

<tva2 : Selection select_id="MEDIAHIGHWAY"> 
<tva2 :Descriptor> 

<tva2 : Ob jectDescription> 

<tva2 : ContentDescription> 

<tva2 : Targetinginf ormation> 

<tva2 : Terminalinf ormation> 

< ! — Add Middleware info here — > 
</tva2 : Terminalinf ormation> 
</tva2 : Targetinginf ormation> 
</tva2 : Con tent Description> 
</tva2 : Ob jectDe script ion> 
</tva2 :Descriptor> 
</tva2 : Selection> 
</tva2 : Choice > 

<tva2 : Choice choice_id="RECORD_ITV_Choice"> 
<tva2 :Condition require="OPENTV"/> 
<tva2 : Selection select_id="RECORD_ITV"> 
<tva2 :Descriptor> 

<tva2 : Ob jectDescription> 

<tva2 : Description>Interactive Application allowing 
you to view player details. Multiple Camera 
Angles etc</tva2 : Description> 
</tva2 : Ob jectDescription> 
</tva2 :Descriptor> 
</tva2 : Selection> 
</tva2 : Choice > 

< ! -- Allow selection of Audio tracks to be recorded. If none are 
selected then no audio will be recorded — > 

<tva2: Choice choice_id="AUDIO_Choice" minSelections="0" 
maxSelections="2 "> 

<tva2 : Selection select_id="EN_AUDIO"> 
<tva2 :Descriptor> 

<tva2 :0b jectDescription> 

<tva2 : ContentDescription> 

<tva2 : ContentProperties> 

<tva2 : ContentAttributes 
xsi : type="tva2 : Audi oAt tribute s Type" > 
<tva2:Coding href="AAC"/> 
<tva2 :NumOfChannels>l</tva2 :NumOf Channels> 

<tva2 : AudioLanguagetype= 
"original">en</tva2 : AudioLanguage> 
</tva2 : ContentAttributes> 
</tva2 :ContentProperties> 
</tva2 : Con tent Description> 
</tva2 : Ob jectDe script ion> 
</tva2 :Descriptor> 
</tva2 : Selection> 

<tva2 : Selection select_id="ES_AUDIO"> 
<tva2 :Descriptor> 

<tva2 :0b jectDescription> 

<tva2 : ContentDescription> 

<tva2 : ContentProperties> 

<tva2 : ContentAttributes 
xsi : type="tva2 : Audi oAt tribute s Type" > 
<tva2: Coding href="AAC"/> 
<tva2 :NumOfChannels>l</tva2 :NumOf Channels> 

<tva2 : AudioLanguage 
type=" dubbed" >es</tva2 : AudioLanguage > 



£75/ 



103 ETSI TS 102 822-2 VI .3.1 (2006-01) 



</tva2 : ContentAttributes> 
</tva2 : ContentProperties> 
</tva2 : Con tent Description> 
</tva2 : Ob jectDe script ion> 
</tva2 :Descriptor> 
</tva2 : Selection> 
</tva2 : Choice > 
<tva2 : Component> 

<tva2 : Condition require="EN_AUDIO" /> 

<tva2 : Resource crid="CRID : //nds . com/soccer/ENAudio"> 
<tva2 : ResourceType 
href ="urn : tva : metadata : cs :MediaType :MP3" /> 
</tva2 :Resource> 
</tva2 : Component> 
<tva2 : Component> 

<tva2 :Condition require="ES_AUDIO" /> 

<tva2 : Resource crid="CRID : //nds . com/ soccer /SPAudio"> 
<tva2 : ResourceType 
href ="urn : tva : metadata : cs :MediaType :MP3" /> 
</tva2 :Resource> 
</tva2 : Component> 

<! — Record Interactive components as appropriate — > 
<tva2 : Component> 

<tva2 : Condition require="RECORD_ITV"/> 
<tva2 : Resource crid="CRID : //nds . com/ sport active" /> 
</tva2 : Component> 
</tva2 : Item> 
</tva2 :Package> 
</tva2 :PackageTable> 
</TVAMain> 



1 0.2.2 Phase 2 example: Educational package 

This example describes an educational package, consisting of an animation and an application to facilitate the study of 
the English language. The application can be run under the Linux OS with at least 16 MB of RAM. 

<?xml version="l .0" encoding="UTF-8 " ?> 
<TVAMain xmlns="urn: tva: metadata: 2 005" 

xmlns : tva2="urn : tva : metadata : extended : 2005" 

xmlns :mpeg21="urn : tva :mpeg21 : 2 005 " 

xmlns :mpeg7="urn : tva :mpeg7 : 2 005 " 

xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 

xsi : schemaLocation="urn : tva : metadata : extended: 2 005 tva2_metadata_3- 
3_vlll .xsd"xsi :tYpe="tva2 :ExtendedTVAMainTYpe"> 
<tva2 : PackageTable> 

<! --Educational Package with application --> 

< I -kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-kk-k > 

<tva2 : Package crid="CRID ://ebs.co.kr/Package/EnglishE ducat ion "> 
<tva2 : Item> 

<tva2 :Descriptor> 

<tva2 : Ob jectDescription> 

<tva2 : ContentDescription 
xsi : type="tva2 : ExtendedContentDescriptionType"> 

<Title>Excercise for english study with an animation 
whose type is an application program</Title> 
<tva2 : ContentProperties> 

<tva2 : ContextAttributes 
xsi : type="tva2 : Appli cat ionContext At tribute s Type" > 
<tva2 : Uninstall>true</tva2 :Uninstall> 
</tva2 : ContextAttributes> 
<tva2 : ContextAttributes 
xsi : type="tva2 : E ducat i onalCon text At tributes Type "> 
<tva2 : EducationalType 
href="urn: tva : educational type : exercise" /> 
</tva2 : ContextAttributes> 
</tva2 :ContentProperties> 
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<tva2 : Targetinginf ormation> 

<tva2 : Terminalinf ormation> 

<tva2 : Systemlnf ormation> 

<tva2 : SupportingOS 
href =" urn : tva : metadata : 
Phase2 : cs : OperatingSystemCS : 2005 : Linux" /> 

<tva2:RAM size="16" unit="MByte"/> 
</tva2 : Systemlnf ormation> 
</tva2 : Terminalinf ormation> 
</tva2 : Targetinginf ormation> 
</tva2 : Con tent Description> 
</tva2 : Ob jectDe script ion> 
</tva2 :Descriptor> 
<tva2 : Component> 

<tva2 : Resource 
crid="CRID : //ebs . co . kr/ Package /EnglishEducati on/An imati on" /> 
</tva2 : Component> 
</tva2 : Item> 
</tva2 :Package> 
</tva2 : PackageTable> 
</TVAMain> 



1 0.2.3 Data broadcasting 

The following XML snippets illustrate a data broadcasting service for drama program called "Damo". The data 
broadcasting service and the "Damo" AV program are broadcast at the same time. The title of the data broadcasting 
service is "Damo Plus," and it consists of two applications. One is the "Damo Story," and it provides information on 
actor, location, summary, etc. The other is the "Damo Fan Cafe," which is an interactive data broadcasting application 
where you can vote for your favourite actor. 

<?xml version="l .0" encoding="UTF-8 " ?> 
<TVAMain xmlns="urn : tva : metadata : 2 005 " 

xmlns : tva2="urn : tva : metadata : extended : 2005" 

xmlns :mpeg21="urn : tva :mpeg21 : 2 005 " 

xmlns :mpeg7="urn : tva :mpeg7 : 2 005 " 

xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 

xsi : schemaLocation="urn : tva : metadata : extended: 2 005 tva2_metadata_3- 
3_vlll .xsd"xsi :type="tva2 :ExtendedTVAMainType"> 
<ProgramDescription> 

<P rogramin format ionTable> 

<ProgramInf ormation pr ogr ami d=" GRID : //www . imbc . com/ Drama/ Damo/ 14-1- 
2005"> 

<BasicDescription> 

<Title>Damo</Title> 
<RelatedMaterial> 
<HowRelated 

href =" urn : tva : howrelatedCS :AssociatedPackage"/> 
<MediaLocator> 

<mpeg7 :MediaUri>CRID : //www . imbc . com/Data/Damo_Plus/14-l- 
2005</mpeg7 :MediaUri> 
</MediaLocator> 
</RelatedMaterial> 
</BasicDescription> 
< /P rogramin format ion> 
</ProgramInf ormationTable> 
</ProgramDescription> 
<tva2 : PackageTable> 

<tva2 : Package crid="CRID: //www. imbc . com/Data/Damo_Plus/14-l-2005/Data"> 
<tva2 :Descriptor> 

<tva2 : Ob jectDe script ion> 

<tva2 : ContentDescription> 

<Title>Damo Plus</Title> 

<Synopsis>Damo Interactive Data Broadcasting 
Service</Synopsis> 
<tva2 : ContentProperties> 
<tva2 : FileProperties> 

<tva2 :FileSize>1441641</tva2 :FileSize> 
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</tva2 : FileProperties> 
</tva2 : ContentProperties> 
</tva2 : Content Description> 
</tva2 :0b jectDescription> 
</tva2 :Descriptor> 
<tva2 : Item> 

<tva2 :Descriptor> 

<tva2 :0b jectDescription> 

<tva2 : ContentDescription> 

<Title>Damo Stroy</Title> 

<Synopsis>Provides brief story for the 

drama</Synopsis> 

<tva2 : ContentProperties> 

<tva2 : ContextAttributes 

xsi : type= 

"tva2 : Dat aBr oadcastingContext At tributes Type "> 

<tva2 : InteractiveContentService>f alse 

</tva2 : InteractiveContentService> 

<tva2 : RenderingStyle FullScreen="true" 
Transparency=" false" /> 
</tva2 : ContextAttributes> 
</tva2 : ContentProperties> 
</tva2 : ContentDescription> 
</tva2 : Ob jectDe script ion> 
</tva2 :Descriptor> 

<tva2 : Reference t ar get =" GRID : //www . imbc . com/Data/Damo_Plus/14-l- 
2005/Data"/> 
</tva2 : Item> 
<tva2 : Item> 

<tva2 :Descriptor> 

<tva2 :0b jectDescription> 

<tva2 : ContentDescription> 

<Title>Damo Fan Cafe</Title> 
<Synopsis>Popularity Vote</Synopsis> 
<tva2 : ContentProperties> 

<tva2 : ContextAttributes xsi : type= 

"tva2 : Dat aBroadcastingContext At tributes Type "> 

<tva2 : InteractiveContentService>true 

</tva2 : InteractiveContentService> 

<tva2 : RenderingStyle FullScreen="true" 
Transparency=" false" /> 

<tva2 :UpdateCycle>PT5S</tva2 :UpdateCycle> 
</tva2 : ContextAttributes> 
</tva2 : ContentProperties> 
</tva2 : ContentDescription> 
</tva2 : Ob jectDescription> 
</tva2 :Descriptor> 
<tva2 : Component> 

<tva2 : Resource crid="CRID : //www . imbc . com/Data/Damo_Plus/14-l- 
2 005/WebData/QuizPage_Kor .class"/> 
</tva2 : Component> 
<tva2 : Component> 

<tva2 : Resource crid="CRID : //www . imbc . com/Data/Damo_Plus/14-l- 
2005/WebData/voct_time.png"/> 
</tva2 : Component> 
<tva2 : Component> 

<tva2 : Resource crid="CRID : //www . imbc . com/Data/Damo_Plus/14-l- 
2 005/WebData/vote_img .png" /> 
</tva2 : Component> 
<tva2 : Component> 

<tva2 : Resource crid="CRID : //www . imbc . com/Data/Damo_Plus/14-l- 
2 005/WebData/quiz.txt"/> 
</tva2 : Component> 
</tva2 : Item> 
</tva2 :Package> 
</tva2 :PackageTable> 
</TVAMain> 
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Publish 

A content creator produces the AV programs and the data broadcast appHcations. The same or a different content 
creator also produces the metadata of both. The metadata of the programs are expressed with the TVA Phase 1 
Metadata schema. Attractor and location information of a program are described in Programlnformation and 
ProgramLocation tables, respectively. 

The metadata of the application is expressed with Phase 2 package schema. As in the case of the TV programs, the 
location information of a data application is included in the ProgramLocation. The ContentDescription of Package 
under the Descriptor is used for the attractor information of data service. The ContentDescription for the Package 
describes the general attractor information of a data broadcasting service. The two applications that consist of the data 
service are described by Descriptor of Item. The ContentDescription of Item describes general attractor information of 
data broadcasting application, and context attributes for data application is described in the 
DataBroadcastingContextAtributes. 

A service provider will publish the information like in the XML snippet above. 

Search/Select 

The Search and Select processes are similar to those in TVA Phase 1 for regular content. If a data service is an AV 
program related service, a consumer typically navigates through the EPG to get a GRID of the AV program. The 
consumer is then able to acquire the GRID of the related package by using the GRID of the AV program. The consumer 
now uses the metadata of the package to find the data service. 

Locate/acquire 

Once the particular data service has been chosen, the data service must be resolved to its constituent files. Given the 
GRID for the data service, the actual location of the required files can be resolved through TVA Phase 1 content 
referencing technology. These files can then be acquired via broadcast or the internet, for example. The XML snippet 
below gives an example of the broadcast case. 

<ContentRef erencingTable> 

<Result CRID="CRID: //www . imbc . com/Data/Damo_Plus/ 14-1-2 005 /Data" status=" resolved" 
complete="true" acquire="all"> 
<CRIDResult> 

<Crid>CRID : //www. imbc.com/Data/Damo_Plus/14-l- 
2005/Carousel2 01_0 930</Crid> 

<Crid>CRID: //www . imbc . com/Data/Damo_Plus/ 14-1- 
2005/Carousel2 03_0 930</Crid> 
</CRlDResult> 
</Result> 

<Result CRID="CRID: //www . imbc . com/Data/Damo_Plus/ 14-1-2 005/Carousel201_0 930" 
status="resolved" complete="true" acquire="all"> 
<LocationsResult> 

<Locator>mhp://65.1000.1; 1 . . l@2005-02-25T21 : 40 : 00+09 : 00</Locator> 
</LocationsResult> 
</Result> 

<Result CRID="CRID: //www . imbc . com/Data/Damo_Plus/ 14-1-2 005 /Carousel203_0 930" 
status="resolved" complete="true" acquire="all"> 
<LocationsResult> 

<Locator>mhp://65.1000.2;2.0.1@2005-02-25T21:40:00+09:00</Locator> 
</LocationsResult> 
</Result> 
</ContentReferencingTable> 



In the XML instance, the GRID for the data service has two GRIDs associated with it. It means that a data service is 
transmitted through two carousels. In the example, the locator information of each GRID is used to locate the carousel. 
For a locator of data broadcasting service by MHP, here is one example format. This format can be used in AGAP data 
broadcast also. 

mhp://[tsid (transport stream id)]. [program number]. [component tag]; 

[carousel id]. [module id].[objectKey]@[date]T[time]+[timezone] 
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View 

After all files for a data broadcasting service have been acquired, data broadcasting middleware can initialize and start 
the service. 

1 0.3 Phase 2 example: Targeting 
1 0.3.1 User environment description 

The XML snippet below describes that the consumer is using a PDA as a TV-Anytime client terminal and the video 
format that the PDA can decode is "AVI." In addition to the terminal related information, the snippet also provides 
information on the current weather conditions. 

Based on this environment, either the PDA can select content in AVI format from the available formats, or the service 
provider can only push contents with "AVI" format under the assumption that this environment description is provided 
to the service provider. In addition, the PDA or the service provider can provide content suitable for the current weather 
condition ('rain'). The selection of the content with a proper format and context can either be based on the program 
description specified by TVA Phase 1 metadata or based on the targeting condition provided by the package tool. 

<?xml version="l .0" encoding="UTF-8 " ?> 
<TVAMain xmlns="urn : tva : metadata : 2 005 " 

xmlns : tva2="urn : tva : metadata : extended : 2005" 

xmlns :mpeg21="urn : tva :mpeg21 : 2 005 " 

xmlns :mpeg7="urn : tva :mpeg7 : 2 005 " 

xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 

xsi : schemaLocation="urn : tva : metadata : extended: 2 005 tva2_metadata_3-3_vlll . xsd" 
xsi:type="tva2 :ExtendedTVAMainType"> 

<UserDe script ion xsi : type="tva2 : ExtendedUserDescriptionType"> 
<tva2 : UsageEnvironment> 

<tva2 : Terminalinf ormationTable> 
<tva2 : Terminalinf ormation> 

<tva2 : Decoderinf ormation 

xsi : type="mpeg21 : VideoCapabi lit ies Type" > 
<mpeg2 1 : Format 
href =" urn :mpeg :mpeg7 : cs : VisualFileFormatCS : 2001 : 7 "> 

<mpeg7 : Name>avi</mpeg7 : Name> 
</mpeg21 : Forma t> 
</tva2 : Decoderinf ormation> 
<tva2 : TerminalType 
href ="urn : tva : metadata : phase2 : cs : TerminalTypeCS : 2005 : 2 "> 
<Name>PDA</Name> 
</tva2 : TerminalType> 
</tva2 : Terminalinf ormation> 
</tva2 : Terminalinf ormationTable> 
<tva2 :NaturalEnvironmentInf ormationTable> 
<tva2 :NaturalEnvironmentInf ormation> 
<tva2 :Weather 

href ="urn : tva : metadata : Phase2 : cs : Weather Type CS : 2005 : 6"> 
<Name>Rainy</Name> 
</tva2 :Weather> 
</tva2 :NaturalEnvironment Inf ormation> 
</tva2 : NaturalEnvironmentInf ormationTable> 
</tva2 : UsageEnvironment> 
</UserDescription> 
</TVAMain> 
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10.3.2 Personalized service 

In a personalized service a service provider makes use, with the consent of the consumer, of consumer profile data (user 
description, user environment and personal profile) in secure environment. 
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Figure 17: Using personal data for a service 

The following XML snippet shows an example instance document of using get_Data and RequestedFields. By using 
these, clients can request specific element or specific attribute values of TVA metadata as well as information defined in 
a table form. 

<?xml version="l .0" encoding="UTF-8 " ?> 

<get_Data xmlns="urn : tva :transport:2005" xmlns : xsi="http : //www . w3 . org/2001/XMLSchema- 
instance" xsi : schemaLocation="urn : tva : transport : 2005 tva_transport_6-l_vl31 . xsd"> 
<QuerYConstraints> 
<PredicateBag> 

<BinaryPredicate fieldID="tvaf: Genre" fieldValue=" :content :3. l"/> 
</PredicateBag> 
</QueryConstraints> 
<RequestedTables> 

<Table type="ProgramInf ormationTable"> 
<RequestedFields> 

<IdentificationBYFieldId f ieldID="tvaf : CRID"/> 
<IdentificationByFieldId fieldID="tvaf : Title" /> 
</RequestedFields> 
</Table> 

<Table type="ProgramLocationTable"> 
<RequestedFields> 

<IdentificationByFieldId f ieldID="tvaf :PublishedS tart Time" /> 
</RequestedFields> 
</Table> 
</RequestedTables> 
</get_Data> 
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The response to the above query is shown below. This example clearly shows that the client receives only the requested 
elements/attributes . 

<?xml version="l .0" encoding="UTF-8 " ?> 

<tns : get_Data_Result serviceVersion=" 1 " xmlns : tns="urn : tva : transport: 2 005" 

xmlns : tva="urn : tva : metadata : 2005" xmlns : xsi="http : //www . w3 . org/2 001/XMLSchema-instance" 

xsi : schemaLocation="urn : tva : transport : 2005 tva_transport_6-l_vl31 . xsd"> 

<tva:TVAMain> 

<tva : ProgramDescription> 

<tva : P rogramin format ionTable> 
<tva : P rogramin format ion 

P r ogr ami d=" GRID : //www . kbs .co.kr:historY/jangbogo"> 
<tva : Bas i cDe script! on > 

<tva : Title>Gangbogo</tva : Title> 
</tva : BasicDescription> 
</tva : Programinf ormation> 
<tva : Programinf ormat ion 

p r ogr ami d=" GRID : //www . kbs .co.kr:cultural/special"> 
<tva : BasicDescription> 

<tva : Title>The report about environment</tva : Title> 
</tva : BasicDescription> 
</tva : Programinf ormat ion> 
</tva : Programinf ormat ionTable> 
<tva : ProgramLocationTable> 
<tva : Broadcast Event > 

<tva : Program crid="GRID : //www . kbs .co.kr:historY/jangbogo"/> 
<tva:PublishedStartTime>2 005-04- 
07T20:45: OOZ</tva:PublishedStartTime> 
</tva : BroadcastEvent> 
<tva : BroadcastEvent> 

<tva : Program crid="CRID : //www .kbs.co.kr:history/ jangbogo" /> 
<tva:PublishedStartTime>2 005-04- 
08120:45 : OOZ</tva :PublishedStartTime> 
</tva : BroadcastEvent> 
<tva : BroadcastEvent> 
<tva : Program 
crid="GRID : //www . kbs .co.kr:cultural/specialreport"/> 

<tva:PublishedStartTime>2 005-04- 
07T22 :45 : OOZ</tva :PublishedStartTime> 
</tva : Broadcast Event > 
</tva : ProgramLocationTable> 
</tva : ProgramDescription> 
</tva:TVAMain> 
</tns : get_Data_Result> 

With the current specification it is possible for the consumer to express whether his personal data is to be used in 
processing the query. The XML snippet below shows how that can be done making use of PersonallnfoUse. By setting 
the PersonallnfoUse attribute to false, the user can signal the service provider not to user the consumer metadata in 
processing his request, i.e. this signals the service provider not to personalize the response to the get_Data request. 

<?xml version="l .0" encoding="UTF-8 " ?> 

<get_Data xmlns="urn : tva : transport: 2 005" xmlns : tva="urn : tva : metadata : 2 005 " 

xmlns : xsi="http : //www . w3 . org/2 001/XMLSchema-instance" 

xsi : schemaLocation="urn : tva : transport : 2005 tva_transport_6-l_vl31 . xsd" 

Personalinf oUse="true"> 
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The XML snippet below shows the use of upload_Personal_Data to transport consumer metadata to the service 
provider. 

<upload_Personal_Data xmlns="urn : tva :transport:2005" xmlns : tva="urn : tva : metadata : 2 005" 
xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 

xsi : schemaLocation="urn : tva : transport : 2005 tva_transport_6-l_vl31 . xsd"> 
<UserInf ormation> 

<UserPreferences> 

</UserPreferences> 
<UsageHistorY> 



</UsageHistory/> 
<UserInf omationTable> 



</UserInf omationTable> 
</UserInf ormation> 
</upload_Personal_Data> 



The use of submitted consumer metadata depends on the poHcy of the service provider. For example, when the 
consumer metadata is accumulated for a long period time, the service provider can use either all the accumulated 
consumer data or the consumer data over a certain period of time. Using submitted consumer metadata can improve the 
service quality by providing an adapted service to the consumer. The XML snippet below shows an example of the 
clear_Personal_Data operation to request the service provider to remove the accumulated consumer data from the server 
collected by upload_Personal_Data. This operation can clear either all submitted data or the data submitted during a 
certain time interval. 

<?xml version="l .0" encoding="UTF-8 " ?> 

<clear_Personal_Data xmlns="urn : tva : transport : 2005" xmlns : tva="urn : tva : metadata : 2005" 

xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 

xsi : schemaLocation="urn : tva : transport : 2005 tva_transport_6-l_vl31 . xsd"> 

<TimeFrom> 

<tva:TimePoint>2 005-04-07T22 : 4 5</tva: TimePoint> 

</TimeFrom> 

<TimeTo> 

<tva:TimePoint>2 003-04-07T22 : 4 5</tva : TimePoint> 

</TimeTo> 

<TargetTable>All</TargetTable> 
</clear_Personal_Data> 



10.4 Phase 2 example: Interstitials 



This example shows how the framework can be used to signal that a particular Spot within a Pod should be substituted 
with another content item when playing back recorded content. 

<?xml version="l .0" encoding="UTF-8 " ?> 
<TVAMain xmlns="urn : tva : metadata : 2 005 " 

xmlns : tva2="urn : tva : metadata : extended : 2005" 
xmlns : int="urn : tva : metadata : interstitial: 2 005" 
xmlns :mpeg21="urn : tva :mpeg21 : 2 005" 
xmlns :mpeg7="urn : tva :mpeg7 : 2 005 " 

xmlns : xsi="http : //www . w3 . org/2 001/XMLSchema-instance" 

xsi : schemaLocation="urn : tva : metadata : extended: 2005 tva2_metadata_3-3_vlll . xsd" 
xsi :tYpe="tva2 :ExtendedTVAMainTYpe"> 
<tva2 : InterstitialTargetingTable> 
<int : Rules> 

<int : rule rule_id="CarpetWorldPromotion"> 
<int: Predicate test="less_than"> 

<int : RuleMethod methodName="urn : sdn: Interstitials : SystemDateTime" /> 
<int :ConstantValue value=" 2005-0 9-0 ITOO :00:00Z"/> 
</int :Predicate> 
</int : rule> 

<int : rule rule_id="CarpetWorldPromotionEndof Sale"> 
<int :PredicateBag type="AND"> 
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<int: Predicate test="less_than"> 

<int : RuleMethod methodName="urn :sdn:Interstitials: SystemDateTime" /> 
<int: Const antValue value="2 005-10-01T00 : 00 : 00Z"/> 
</int :Predicate> 
<int: Predicate test="greater_than"> 

<int : RuleMethod methodName="urn : sdn :Interstitials: SystemDateTime" /> 
<int : Const antValue value="2 005-0 9-2 9T00 : 00 :00Z"/> 
</int :Predicate> 
</int : PredicateBag> 
</int : rule> 

<int : rule rule_id=" Parent alControl"> 
<int: Predicate test="less_than"> 

<int : RuleMethod methodName="urn : sdn: Interstitials : Parent alControl"/> 
<int : Const ant Value value=" 16" /> 
</int :Predicate> 
</int : rule> 
</int :Rules> 
<int : InterstitialTable> 
<int : InterstitialBreak> 

<int : InterstitialBreakSelectionRule> 
<int : Predicate test="equals"> 

<int : RuleMethod methodName="urn :sdn:Interstitials: targetPodID" /> 
<int :ConstantValue value="123"/> 
</int :Predicate> 
</int : InterstitialBreakSelectionRule> 
<int : SpotSubstitution> 

<int : SpotSelectionRule> 
<int : PredicateBag> 

<int :Predicate test="equals"> 

<int : Con St ant Value value="crid : / / too . com/ Ho vis " /> 
<int : RuleMethod methodName="urn : s dn : Interstitials: Spot ID "/> 
</int:Predicate> 
</int:PredicateBag> 
</int : SpotSelectionRule> 
<int : ReplacementSpot> 

<int : Condition require="CarpetWorldPromotion" /> 
<int : Content Re f crid="crid: 1 1 too . com/CarpetWorld" /> 
</int : ReplacementSpot> 
<int : ReplacementSpot> 

<int : Condition require="CarpetWorldPromotionEndof Sale" /> 
<int : Content Re f crid="crid: I / too . com/ CarpetWorldEndOf Sale" /> 
</int : ReplacementSpot> 
</int : SpotSubstitution> 
</int : InterstitialBreak> 
</int : InterstitialTable> 
</tva2 : InterstitialTargetingTable> 
</TVAMain> 



At the point of play back the terminal shall check to see if a Pod with a Podid of "XYZ" exists within the recorded 
content. 

NOTE: Identification of the Pod is out of scope of the TV-Anytime specifications. 

If it does then the system shall replace the Spot with a Spotid of "crid://foo.com/Hovis" with either the "Carpet World 
Promotion" content item or the "Carpet World End Of Sale" content item depending on the date at which the content is 
played back. 

If neither of the rules are satisfied then the system shall play out the original content item i.e. "crid://foo.com/Hovis". 
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The following example shows how a number of Avail substitutions and Spot substitutions can be combined together to 
support more complex scenarios. 

<?xml version="l .0" encoding="UTF-8 " ?> 
<TVAMain xmlns="urn : tva : metadata : 2 005 " 

xmlns : tva2="urn : tva : metadata : extended: 2005" 
xmlns : int="urn : tva : metadata : interstitial: 2 005" 
xmlns :mpeg21="urn : tva :mpeg21 : 2 005 " 
xmlns :mpeg7="urn : tva :mpeg7 : 2 005 " 

xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 

xsi : schemaLocation="urn : tva : metadata :extended:2005 tva2_metadata_3-3_vlll . xsd" 
xsi:type="tva2 :ExtendedTVAMainTYpe"> 
<tva2 : InterstitialTargetingTable> 
<int : Rules> 

<int:rule rule_id="peaktime"> 
<int :PredicateBag type="AND"> 

<int: Predicate test="greater_than"> 

<int : RuleMethod methodName="urn :sdn:Interstitials: SystemTime" /> 
<int : Const antValue value="18 :00:00Z"/> 
</int :Predicate> 
<int : Predicate test="less_than"> 

<int : RuleMethod methodName="urn :sdn:Interstitials: SystemTime" /> 
<int : Const antValue value="21 :00:00Z"/> 
</int :Predicate> 
</int : PredicateBag> 
</int : rule> 

<int : rule rule_id="Breakf ast_time"> 
<int :PredicateBag type="AND"> 

<int : Predicate t est=" great er_than"> 

<int : RuleMethod methodName="urn :sdn:Interstitials: SystemTime" /> 
<int : Const antValue value="06: 00:00Z"/> 
</int :Predicate> 
<int: Predicate test="less_than"> 

<int : RuleMethod methodName="urn :sdn:Interstitials: SystemTime" /> 
<int : Const antValue value="10 :00:00Z"/> 
</int :Predicate> 
</int : PredicateBag> 
</int : rule> 

<int : rule rule_id="ParentalControl"> 
<int: Predicate test="less_than"> 

<int : RuleMethod methodName="urn : sdn: Interstitials : Parent alControl"/> 
<int : Con St ant Value value=" 16"/> 
</int :Predicate> 
</int : rule> 
</int :Rules> 
<int : InterstitialTable> 
<int : InterstitialBreak> 

<int : InterstitialBreakSelectionRule> 
<int : Predicate test="equals"> 

<int :ConstantValue value="XYZ"/> 

<int : RuleMethod methodName="urn : sdn: Interstitials: tar getPodID"/> 
</int :Predicate> 
</int : InterstitialBreakSelectionRule> 
<int : PodSubstitution> 
<int : ReplacementPod> 

<int : Condition require="peaktime" /> 
<int : Spot crid="crid : / / too . com/per sil" /> 
<int : Spot crid="crid: / / too . com/ ford" /> 
</int : ReplacementPod> 
<int : ReplacementPod> 

<int : Condition require="Breakf ast_time" /> 
<int : Spot crid="crid : / / too . com/McDonalds Breakfast" /> 
<int : Spot crid="crid : / / too . com/ AlpenCe real" /> 
</int : ReplacementPod> 
<int :ReplacementPod PodId="89658"> 

<int : Condition except="peaktime Breakf ast_time"/> 
<int : Spot crid="crid : 1 1 too . com/ Joes Car Lot " /> 
<int : Spot crid="crid : I / too . com/AmateurDramatics" /> 
</int : ReplacementPod> 
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</int : PodSubstitution> 
<int : SpotSubstitution> 

<int : SpotSelectionRule> 

<int : Predicate test="equals"> 

<int : RuleMethod methodName="urn :sdn:Interstitials:SpotId"/> 
<int : Con St ant Value value="crid : 1 1 too . com/ Joes Car Lot " /> 
</int : Predicate> 
</int : SpotSelectionRule> 
<int : ReplacementSpot> 

<int : Condition require="ParentalControl"/> 
<int : Content Re f crid="crid: / / too . com/ToyAdvert 1 " /> 
</int : ReplacementSpot> 
</int : SpotSubstitution> 
</int : InterstitialBreak> 
</int : InterstitialTable> 
</tva2 : InterstitialTargetingTable> 
</TVAMain> 

The above example shows how Spot substitution can be used alongside Pod substitution. When performing play back of 
a recorded content item, the system shall check to see if it contains a pod with a Podid of "XYZ". If it does then this 
Pod shall be replaced by one of 3 substitution Pods depending on the time of day at which the content is being played. If 
playback ours during peak time then the system shall play the Persil and Ford advert. If its breakfast time then the 
system shall play the McDonalds breakfast and Alpen Cereal advertisement. At all other times it will play the Car lot 
and Amateur Dramatics advert. 

Then system shall then evaluate the SpotSubstitution declarations, to see if any of the spots within the substitution Pod 
should be replaced. As a consequence, in this example if the Pod containing the JoesCarLot Advert was selected and the 
viewer was under 16 years of age then the JoesCarLot advert would be replaced by a Toy advert. 

In an environment where the transport system does not support pod positioning (e.g. in a non-broadcasting service 
environment, such as IP -cast), pod identification can be provided by the TV-Anytime specification using SegmentGroup 
information, as shown in the following example. 

<?xml version="1.0" encoding="UTF-8 " ?> 
<TVAMain xmlns="urn : tva : metadata : 2 005 " 

xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 

xsi : schemaLocation="urn : tva : metadata : 2005 tva_metadata_3-l_vl31 . xsd"> 
<ProgramDescription> 

<SegmentInf ormationTable> 
<SegmentList> 

< Segment Information segmentld=" segment 01 "> 

<ProgramRef crid="crid : //ybc . com/myprograml " /> 
<SegmentLocator> 

<MediaRelIncrTimePoint>30000</MediaRelIncrTimePoint> 
</ Segment Locat or > 
</ Segment Information> 
< Segment In format ion segment I d=" segment 02 "> 

<ProgramRef crid="crid : //ybc . com/myprograml " /> 
<Segment Locat or > 

<MediaRelIncrTimePoint>60010</MediaRelIncrTimePoint> 
</ Segment Locat or > 
< /Segment I nformation> 
< Segment In format ion segment I d=" segment 03 "> 

<ProgramRef crid="crid : //ybc . com/myprograml " /> 
< Segment Locat or > 

<MediaRelIncrTimePoint>100000</MediaRelIncrTimePoint> 
</ Segment Locat or > 
< /Segment I nformation> 
<Segment In format ion segment I d=" segment 04 "> 

<ProgramRef crid="crid : //ybc . com/myprograml " /> 
<Segment Locat or > 

<MediaRelIncrTimePoint>142 000</MediaRelIncrTimePoint> 
</ Segment Locat or > 
< /Segment I nformation> 
< Segment In format ion segment I d=" segment 05 "> 

<ProgramRef crid="crid : //ybc . com/myprograml " /> 
<Segment Locat or > 
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<MediaRelIncrTimePoint>183000</MediaRelIncrTimePoint> 
</ Segment Locat or > 
< /Segment I nformation> 
</SegmentList> 
<SegmentGroupList> 

< Segment Group Information groupId=" sgroupOOl "> 

<ProgramRef crid="crid: //ybc . com/myprograml "/> 
<GroupType xsi : tYpe=" Segment GroupTypeType" 
value="insertionPoints" /> 

<Segments ref List="segment01 segment02 segment03 segment04 
segment 05 "/> 
</ Segment Groupin format ion> 
</ Segment GroupLi St > 
</Segment Inf ormationTable> 
</ProgramDescription> 
</TVAMain> 

The above example TVA document completely describes 5 Pods, each of which are separated by about 15 minutes. In 
this example, the segmentID concatenated with CRID should be used as a Podid as defined in SP003-4 so that exact 
position within the given program is specified by each SegmentLocator. For example, the identification for the second 
insertion point (pod) is "segment02//crid://ybc. com/myprograml". 

1 0.5 Phase 2 example: Sharing - metadata exchange 

The scenarios below cover the specifications that explicitly add support for the exchange of metadata. 

1 0.5. 1 Transfer profile to another device 

This clause addresses the following scenario: 

"Using his rented 3G mobile phone, Michael gets access to a UK content provider's menu of contents. He 
knows that the provider has Manchester United matches on the menu. He wants to watch them the way he 
likes, so he has his user profiles transferred from his home PDR in Hong Kong to the UK content provider so 
that the latter can know exactly what he likes. As a result, clips of Man U goals are streamed to his phone 
while in the UK". 

In this scenario, the 3G mobile phone (UKMobile) would provide Michael's identity. It also helps the UK content 
provider to discover Michael's home PDR - it is a Discovery Service host as is called in Web Services. Michael's PDR 
in Hong Kong (HKPDR) provides Michael's user profiles (UserPreferences and UsageHistory in this case). 

The UK Content provider (UKCP) is the service provider, providing content (football games including Manchester 
United). 

A sequence of events that would be involved in the exchange of user profiles in this scenario may be described as 
follows. UKCP does not have Michael's personal information, and so it needs to obtain his personal profiles from other 
services. On Michael's request, UKCP asks UKMobile for information on offered services and resources of other sites. 
This can be done by sending a query message for service discovery. 
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<soapenv : Envelope xmlns : soapenv="http : //schemas . xmlsoap . org/ soap /envelope/" 

xmlns :xsd="http: //www. w3 . org/2 001/XMLSchema" xmlns : xsi = "http : //www. w3 . org/200 1/XMLSchema- 

instance"> 

<soapenv : Header> 
</soapenv: Header> 
<soapenv : Body> 

<disco: Query id="NTT43EBDA48A7 965082DA2 84C13DE33EFDE" 
xmlns : disco := "urn : liberty :disco:2003-08"> 
<disco : Resource ID>https : //www. UKMobile . com: 84 43</disco: ResourceID> 
<disco : Requestedisco : erviceType> 

<disco : ServiceType>urn : tva : metadata :user</ disco: ServiceType> 
< disco :Options> 

<disco : Option>urn : tva : metadata : Use rP references 
</ disco :Option> 

<disco : Option>urn : tva : metadata :UsageHistory</disco: Option> 
</disco : Options> 
</ disco :RequestedServiceType> 
</disco:Query> 
</soapenv : Body> 
</soapenv : Envelope> 

On receiving this query message for service discovery, UKMobile sends back a response message giving the requested 
service types and resource, if there is any. This will show that HKPDR has such service. 

<soapenv : Envelope xmlns : soapenv="http : //schemas . xmlsoap . org/ soap/ envelope/ " 

xmlns :xsd="http: //www. w3 . org/2 001/XMLSchema" xmlns : xsi = "http : //www.w3 . org/200 1/XMLSchema- 

instance"> 

<soapenv : Header> 
</soapenv: Header> 
<soapenv : Body> 

<disco:QueryResponse id="NTTE6CF51BEB032 0300DF0F4070CD04DlB6" 
xmlns : disco : ="urn : liberty : disco: 2 003-08 "> 
<disco: Status code="disco:OK"/> 

<disco : ResourceOf f ering entryID="uuid:lclccaeb-0c3 6-22 9b-d510- 
7ae33406ada4"> 

<disco:ResourceID>https : //HKPDR: 8443/metadata/prof lie 
</disco:ResourceID> 

<disco : Servicelnstance> 
<disco : ServiceType>urn : tva : metadata :user</ disco: ServiceType> 
<disco: Provider ID>https: //HKPDR: 8 443/metadata/prof ile</ 
disco : ProviderID> 

<disco:Description> 

<disco : SecurityMechID>urn :liberty:security:2003- 
8 :TLS:X50 9</disco:SecurityMechID> 
<disco : SecurityMechID>urn :liberty:security:2003- 
08 :TLS:null</disco:SecurityMechID> 
<disco:Endpoint>https : //HKPDR: 8443/metadata/ 
pro file</ disco: Endpoint> 
</disco : Description> 
</disco:ServiceInstance> 
<disco : Options> 

<disco : Option>urn : tva : metadata :UserPreference</disco: Option> 
<disco : Option>urn : tva : metadata :UsageHistory</disco: Option> 
<disco : Option>urn : liberty : id-si s-pp :cn</ disco: Option> 
<disco : Option>urn : liberty : id-si s-pp : informalName< /disco : Option> 
</ disco :Options> 

</disco : ResourceOf fering> 
</disco : QueryResponse> 
</soapenv : BodY> 
</soapenv : Envelope> 
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UKCP in turn gets access to HKPDR, asking for its offered services. After receiving Hoper's offering UKCP sends a 
query message for personal profiles to HKPDR so as to obtain Michael's personal information. 

<soapenv: Envelope xmlns : soapenv="http : //schemas . xmlsoap . org/ soap/ envelope/ " 
xmlns:xsd="http: //www. w3 . org/2 001/XMLSchema" xmlns : xsi="http : //www . w3 . org/200 1/XMLSchema- 
instance"> 

<soapenv : Header > 
</soapenv: Header> 
<soapenv : Body> 

<tvapp: Query id="NTT2 7 9922C2 0F14 7 3B04D14F21F5B92 98 90" 
xmlns : tvapp="urn : tva : id-si s-pp :2 003-0 8"> 

<tvapp :ResourceID>https : //HKPDR/metadata/userprof ile</tvapp : ResourceID> 
<tvapp : Query It em includeCommonAttributes="0"> 

<tvapp : Select >/tvapp : TVAMain/tvapp : UserDe script ions/ 
tvapp : UserPref erences/tvapp : FilteringAndSearchPref erences 
</tvapp : Select> 
</tvapp : Queryltem> 
< tvapp : Query It em includeCommonAttributes="0"> 

< tvapp : Select >/tvapp : TVAMain/tvapp : UserDe script ions/ 
tvapp : UserPref erences/tvapp : Brows ingP references 
</tvapp : Select> 
</tvapp : Queryltem> 
< tvapp : Query It em includeCommonAttributes="0"> 

< tvapp: Select >/tvapp: TVAPP/tvapp:UsageHistory</pp : Select > 
</tvapp : Queryltem> 
</tvapp : Query> 
</soapenv : Body> 
</soapenv : Envelope> 

After receiving the query, HKPDR then puts the requested personal information in the response message and sends it to 
UKCP, and UKCP receives Michael's profiles, namely his UserPreferences and UsageHistory. 

<soapenv: Envelope xmlns : soapenv="http : //schemas . xmlsoap . org/ soap/ envelope/ " 

xmlns :xsd="http: //www. w3 . org/2 001/XMLSchema" xmlns : xsi = "http : //www.w3 . org/20 01 /XMLSchema- 

instance"> 

<soapenv : Header> 
</soapenv: Header> 
<soapenv : Body> 

<tvapp:QueryResponse timeStamp="2004-03-10T05 : 59 : 06Z" 
xmlns : tvapp="urn : tva : metadata : user"> 
<tvapp : Status code="tvapp : OK" /> 
<tvapp :Data> 
<tvapp : TVAMain> 

< tvapp :UserDescription> 

< tvapp :UserPreferences> 

< tvapp :UserPreference> 
<mpeg7 : FilteringAndSearchPref erences preferenceValue="90" 
xmlns :mpeg7="urn : tva :mpeg7 : 2 005"> 

<mpeg7 :ClassificationPreferences> 

<mpeg7 : Genre href="urn :mpeg : GenreCS"> 

<mpeg7 :Name>Soccer</mpeg7 :Name> 
</mpeg7 : Genre> 
</mpeg7 : Classif icationPref erences> 
<mpeg7 :CreationPref erences> 

<mpeg7 : Creator pref erenceValue="70 "> 
<mpeg7 : Role 
href="urn:tva:metadata:cs : TVARoleCS : 2005 : V43"> 

<mpeg7 : Name>Participant</mpeg7 : Name> 
</mpeg7 : Role> 

<mpeg7 : Agent xsi : type="mpeg7 : OrganizationType"> 
<mpeg7 : Name> 

<mpeg7 : GivenName>Manchester 
United</mpeg7 : GivenName> 
</mpeg7 :Name> 
</mpeg7 :Agent> 
</mpeg7 : Creator> 
</mpeg7 : Great ionPreferences> 
</mpeg7 : FilteringAndSearchPref erences> 
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</tvapp : UserPref erence> 
</tvapp :UserDescription> 
</tvapp : TVAMain> 

</tvapp:Data> 
<tvapp :Data> 

<tvapp : UsageHistory> 
</tvapp : UsageHistorY> 
</tvapp:Data> 
</tvapp : QueryResponse> 
</soapenv : BodY> 
</soapenv : Envelope> 



1 0.5.2 Recommend content to a friend 

TS 102 822-8 [13] allows the user to transfer metadata between devices, with an appropriate instruction. The 
specification allows the encapsulation of all forms of TV-Anytime data. One of the nice features of TS 102 822-8 [13] is 
the ability to recommend a piece of content to a friend. In this example the user sends the following data to a friend via 
email, recommending an episode of Foxes. 

<?xml version="l .0" encoding="UTF-8 " ?> 
<CoreData xmlns="urn : tva : Cor eData : 2005" 
xmlns :mpeg7="urn : tva :mpeg7 : 2 005" 
xmlns : tva="urn : tva : metadata : 2005" 

xmlns : CR="http : //www . tv-anytime . org/2002 /0 6/Content Referencing" 
xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 
xsi : schemaLocation="urn : tva :CoreData:2005 tva_core_data_8_vlll . xsd"> 
<SelectedContent id="CRID : //re solver . com/f oxes/ episode 1 "> 

<tva:TVAMain version="03" xml : lang="en" publisher=" . . . " 
publicationTime="2 005-03-1 6T14: 13: 00. 00 + 8: 00 "> 

<tva : CopyrightNotice> . . . </tva : CopyrightNotice> 
<tva : ProgramDescription> 

<tva : P rogramln format ionTable> 
<tva : Programinf ormation 

pr ogr ami d=" GRID : //resolver . com/f oxes /episode 1 "> 
<tva : BasicDescription> 

<tva:Title>Foxes</tva:Title> 
</tva : Bas i cDe script! on > 
</tva : Programinf ormation> 
</tva : Programinf ormationTable> 
<tva : ProgramLocationTable> 

<tva : Broadcast Event servicelDRef ="bcastl2 "> 

<tva:Program crid="CRID : //resolver . com/foxes/episodel" /> 
<tva:ProgramURL>dvb: //I . 4ee2 . 3f 4/</tva :ProgramURL> 
<tva:PublishedStartTime>2 005-03- 
16T18 : 00:00 . 00+08 : 00</tva :PublishedStartTime> 
<tva : PublishedDuration>PTlH</tva : PublishedDuration> 
</tva :BroadcastEvent> 
</tva : ProgramLocationTable> 
</tva : ProgramDescription> 
</tva:TVAMain> 

<WSIFServerAddress>http : //resolver. com/tva</WSIFServerAddress> 
<Action> 

<Type href ="urn : tva : core_data : cs : ActionTypeCS : 2 005 : recommend" /> 
</Action> 
</SelectedContent> 
</CoreData> 



In the example shown, the user sends a TVAMain document that contains Programlnformation for the recommended 
programme along with the ProgramLocation information for the broadcast. A pointer is also given to the appropriate 
resolving service so that the receiver can accurately resolve the content (they could include the location resolution table 
if they wanted). The final element describes the "recommend" action associated with the content. 
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1 0.5.3 Web browsing to select content and metadata acquisition 

This scenario implies the following steps: 

• The customer uses the Web browser available in its PDR to access an EPG located on a web site. 

• The customer browses the EPG and selects content. A record button on the EPG page allows the customer to 
download the metadata associated to the selected content in order to program the content recording. 

• The customer presses the record button and get the metadata (as specified in TS 102 822-8 [13]) associated to 
the selected content in its PDR. 

Here is an example of the file received from the Web site containing metadata information and action ("record") to be 
taken on the content associated with this metadata: 

<?xml version="l .0" encoding="UTF-8 " ?> 
<CoreData xmlns="urn : tva : Cor eData : 2005" 
xmlns :mpeg7="urn : tva :mpeg7 : 2 005 " 
xmlns : tva="urn : tva : metadata : 2005" 

xmlns : CR="http : //www. tv-anytime . org/2002 /0 6/Content Referencing" 
xmlns : xsi="http : //www . w3 . org/2 001/XMLSchema-instance" 
xsi : schemaLocation="urn : tva : CoreData : 2 005 tva_core_data_8_vlll . xsd"> 
<SelectedContent id="CRID : //re solver . com/f oxes/ episode 1 "> 

<tva:TVAMain version="03" xml : lang="en" publisher=" . . . " 
publicationTime="2 005-03-1 6T14: 13: 00. 00 + 8: 00 "> 

<tva : CopyrightNotice> . . . </tva : CopyrightNotice> 
<tva : ProgramDescription> 

<tva : Programinf ormationTable> 
<tva : Programinf ormation 

pr ogr ami d=" GRID : //resolver . com/f oxes /episode 1 "> 
<tva : BasicDescription> 

<tva:Title>Foxes</tva:Title> 
</tva : BasicDescription> 
</tva : Programinf ormation> 
</tva : Programinf ormationTable> 
<tva : ProgramLocationTable> 

<tva : Broadcast Event servicelDRef ="bcastl2 "> 

<tva:Program crid="CRID : //resolver . com/f oxes/episodel" /> 
<tva:ProgramURL>dvb: //I . 4ee2 . 3f 4/</tva :ProgramURL> 
<tva:PublishedStartTime>2 005-03- 
16118:00:00. 00+08: 00</tva :PublishedStartTime> 
<tva:PublishedDuration>PTlH</tva:PublishedDuration> 
</tva : BroadcastEvent> 
</tva : ProgramLocationTable> 
</tva : ProgramDescription> 
</tva:TVAMain> 

<WSIFServerAddress>http : //resolver. com/tva</WSIFServerAddress> 
<Action> 

<Type href="urn: tva : core_data : cs : ActionTypeCS :2004:record"/> 
</Action> 
</SelectedContent> 
</CoreData> 

• The PDR asks the customer for record programming confirmation. 

• On user confirmation, metadata is stored for the selected content in the PDR with the already existing 
metadata. If location resolution is not provided within the metadata, it will take place as specified by 
TV Anytime specification and at the end the recording will be programmed. 

• From now on, the PDR will handle this new record request in the same way as the record requests coming 
from the normal TV Anytime selection process. This means that if GRID re-resolution is to be done, it will be 
done as specified by TV Anytime specification. 
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10.6 Phase 2 example: Remote programming using a Networked 
Digital Recorder (NDR) 

These are the scenarios considered in this clause and involving a Network Digital Recorder (NDR): 

• NDR programming for future recording. 

• NDR programming for immediate recording. 

• NDR programming for consumption by another device. 

1 0.6.1 NDR programming for future recording 

This scenario involves the following steps: 

• The customer uses TV Anytime technologies on his PDR to select content. 

• Then he discovers that the selected content instance overlaps with other content he is interested in. He decides 
to send a record request to the NDR Service able to record this content instance. 

Here is the record request from the PDR to the NDR: 



<Re CO rdRe quest > 












<SubscriptionId>34 56- 


4567- 


-5677-4321</Sub 


scription 


Id> 


<ContentId CRID= 


'crid 


: //broadcaster . com/ 


ajcnd"/> 




<Locator>dvb: //I 


.4ee2 


.3fa 


4f 5</Locator> 






</RecordRequest> 













• His PDR receives a record request acknowledgement containing the date and time at which this content is 
expected to be available. 

Here is the positive response to the Record Request: 



<RecordRequestResult> 

<RequestId>4 5U7 53-4 52</RequestId> 
<Time2Call>2 004-07-1 5T20: 35: 00. 00</Time2Call> 
<RecordingCharge currency="EUR">2</RecordingCharge> 
<ConservationDelay>PT12H</ConservationDelaY> 
</RecordRequestResult> 



• At that date and time, the PDR contacts the NDR to make sure that the content is really available or to obtain a 
new date and time of availability if there is a schedule change. 

Here is the request from the PDR to the NDR to inquire about the content availability: 



<RecordStatus Request Id=" 4 5U7 53-4 52 "/> 



• When the NDR response confirms the availability of the recorded content, the PDR informs the customer. 
Here is the NDR response confirming the availability of the content: 



<RecordStatusResult Request Id=" 4 5U7 53-4 52 "> 
<ContentAvailable> 
<ContentURL>ftp: //ccett . fr/contentl .mp2</ContentURL> 
<ConservationDeadline>2004-07-17T2 : 30 : 00 . 00</ConservationDeadline> 
</ Content Aval lable> 
</RecordStatusResult> 



On end-user request, the PDR gets the recorded content as specified (either by streaming or downloading). 
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1 0.6.2 NDR programming for immediate recording 

This scenario involves the following steps: 

The customer is watching time shifted live content using his PDR. 

Somebody else comes in and wants to watch the live event being broadcast soon on another channel. 



• 



• 



The customer can then request an NDR to immediately record the content being broadcast on the current TV 
channel. It should be noted that only a part of the content will be recorded by the NDR. 



<Re CO rdRe quest > 

<SubscriptionId>34 5 6-4 5 67-5 677-432 l</SubscriptionId> 
<Locator>dvb: 111. 4ee2 . 3fa; 4f 5</Locator> 

</RecordRequest> 



expected to be available. 



<RecordRequestResult> 

<RequestId>4 5U7 53-4 52</RequestId> 
<Time2Call>2 004-07-1 5T20: 35: 00. 00</Time2Call> 
<RecordingCharge currencY="EUR">2</RecordingCharge> 
<ConservationDelay>PT12H</ConservationDelaY> 

</RecordRequestResult> 



• The customer carries on watching TV until the beginning of the live event broadcast and leaves the room. 

• The second person watches the live event and at the end, the first person comes back and asks the PDR to get 
the recorded content as specified (either by streaming or downloading). 



Request from the PDR to the NDR: 



<RecordStatus RequestId="45U753-452"/> 



Response from the NDR when the content is available (here in streaming mode, so maybe before complete content 
recording if the NDR is able to play a content while recording). 

<RecordStatusResult Request Id=" 4 5U7 53-4 52 "> 
<ContentAvailable> 
<ContentURL>rtsp: //ccett . f r/contentl .mp2</ContentURL> 
<ConservationDeadline>2004-07-17T2 : 30 : 00 . 0</ConservationDeadline> 
</ Content Aval lable> 
</RecordStatusResult> 

NOTE: The content made available after recording by the NDR is not a complete program, it is just the last part 
of the content starting from the time when the record request was accepted. 

1 0.6.3 NDR programming for consumption by anotlner device 

The customer is in his office and discovers that tonight an interesting content will be broadcast but he knows that he 
will be soon on the move and so decides to record the TV Content for later viewing on its PDA. 

This scenario involves the following steps: 

The customer uses TV Anytime technologies or EPG Web browsing on his office PC to select content. 



• 



• 



Then he discovers that the selected content instance overlaps with other content he wanted to watch tonight. 
He decides to send a record request to the NDR Service able to record one of the two content instances 
indicating the media format and bit rate suitable for the PDA on which he wants to watch the content. 
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Request from the PDR to the NDR to record content and to convert the audio and the video coding for dehvery over 
FTP: 

<RecordRequest> 

<SubscriptionId>2 34 5-54 67-4FGS-2 3B</SubscriptionId> 
<ContentId CRID="crid: //www . f rancetelecom. com/content2 45" /> 
<Locator>dvb: //I . 4ee2 . 3fa; 4f 5</Locator> 
<DeliveryMediaFormat> 

<metadata : Bit Rate variable="true" 
maximum= " 2 8 " > 1< /met adat a : BitRat e> 
<metadata : AudioAttributes> 
<metadata : Coding 

href =" urn :mpeg :mpeg7 : cs : AudioCodingFormatCS : 2001 : 5"> 
<metadata :Name xml : lang="en">AMR</metadata : Name> 
</metadata : Coding> 
< /met adat a : AudioAttributes> 
<metadata : VideoAttributes> 
<metadata : Coding 

href="urn :mpeg :mpeg7 : cs : Visual CodingFormatC S :2001:3.1"> 
<metadata:Name xml : lang="en">MPEG-4 Visual Simple 
Prof ile</metadata :Name> 
</metadata : Coding> 
</metadata : VideoAttributes> 
</DeliveryMediaFormat> 

<Protocol tYpe="urn:tva:RP:cs :ProtocolTypeCS : 2004 : ftp"/> 
</RecordRequest> 

• His PC is informed that the selected content is to be recorded by the NDR and will be available after a certain 
date and time. He transfers the NDR response to his PDA. 

Here is an example of NDR response (to be transferred to the PDA): 

<RecordRequestResult> 

<RequestId>4 5U7 53-4 52</RequestId> 

<Time2Call>2 004-07-1 5T20: 35: 00. 00</Time2Call> 

<RecordingCharge currencY="EUR">2</RecordingCharge> 

<ConservationDelay>PT12H</ConservationDelay> 
</RecordRequestResult> 

• At the date and time, the PDA calls the NDR to make sure that the content is really available or to obtain a 
new date and time of availability if there is a schedule change. 

Here is the request from the PDA to the NDR to inquire about the content availability: 

<RecordStatus Request Id=" 4 5U7 53-4 52 "/> 

• When the NDR response confirms the availability of the recorded content, the PDA informs the customer. 

Here is an example of the response confirming the content availability: 

<RecordStatusResult Request Id=" 4 5U7 53-4 52 "> 
<ContentAvailable> 
<ContentURL>ftp: //ccett . fr/contentl .mp2</ContentURL> 
<ConservationDeadline>2004-07-17T2 : 30 : 00 . 0</ConservationDeadline> 
</ Content Aval lable> 
</RecordStatusResult> 

• On end-user request, the PDA gets the recorded content as specified (either by streaming or downloading). 
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The following figure explains the different interactions with an NDR. 

UDDI 
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Search for MDR able 



to record cl lannels 1 , 2 & 3 
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PDA 
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NDR Service publishing 



(NDR Capability Description) 



Record request (Contentid, Subscriptionid) 



Requestid 



Record request status (Requestid) 



Content ready 



Get RMPI & AV content (combined or separately) 



Figure 18: Interactions withi an NDR using UDDi for NDR discovery 

Figure 18 illustrates: 

• The use of the UDDI repository for NDR declaration and discovery. 

• The NDR subscription from the PDR on a Web site. 

• The transfer of the "subscriptionid to other user devices (here the office PC). 

• The record request to the NDR from the office PC for a content to be acquired by a PDA. 

1 0.7 Phase 2 example: Coupons 

The example below describes: 

• Content with reward coupon. 

• Coupon "Buy 3 movies, get one free". 

<?xml version="l .0" encoding="UTF-8 " ?> 
<TVAMain xmlns="urn : tva : metadata : 2 005 " 

xmlns :tva2="urn:tva : metadata : extended : 2005" 

xmlns :mpeg21="urn : tva :mpeg21 : 2 005" xmlns :mpeg7="urn : tva :mpeg7 : 2005" 
xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 

xsi : schemaLocation="urn : tva : metadata : extended: 2005 tva2_metadata_3-3_vlll . xsd" 
xsi :type="tva2 :ExtendedTVAMainTYpe">xsi : type="tva2 :ExtendedTVAMainTYpe"> 
<ProgramDescription> 

<ProgramInf ormationTable> 

<ProgramInf ormation programId="crid: //www. chl . com/titanic"> 

<BasicDe script ion xsi : type="tva2 : ExtendedContentDescriptionType"> 
<Title xml:lang="en-us" tYpe="main">Titanic</Title> 
<Synopsis xml : lang="en-us" length="short ">a great 
movie</SYnopsis> 
<PurchaseList> 

<PurchaseItem xsi : tYpe="tva2 : ExtendedPurchaseItemTYpe"> 
<Price currencY="EUR">5</Price> 
<tva2 : RewardCoupon> 
<tva2 : CouponRef > 

<tva2 : CouponldRef >Channell- 
2004A</tva2 :CouponIdRef > 
</tva2 : CouponRef > 
</tva2 : RewardCoupon> 
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</PurchaseItem> 
</PurchaseList> 
</BasicDescription> 
< /Programin format ion> 
</ProgramInf ormationTable> 
</ProgramDescription> 
<tva2 : CouponTable> 

<tva2 : CouponDescription requiredNumber="3 " couponId=" Channel 1-2 004A" 
acquisitionMode="linkedToContent "> 
<tva2 : CouponValue> 

<tva2 : ReductlonPercentage>100</tva2 :ReductlonPercentage> 
</tva2 : CouponValue> 
<tva2 : ContentTarget> 

<tva2 : Genre href =" urn : tva : metadata : cs : FormatCS :2005:3.5.7.3" 
type="main"/> 
</tva2 : ContentTarget> 

<tva2 : CouponText xml : lang="en-us">You get a fourth movie free for 
any purchase of 3 movies</tva2 : CouponText> 
</tva2 : CouponDescription> 



</tva2 : CouponTable> 
</TVAMain> 



The example below describes a free coupon for a 20 % discount on all movies valid for the Christmas period 
(from 2P' of December to the 3P0: 

<?xml version="l .0" encodlng="UTF-8 " ?> 
<TVAMain xmlns="urn : tva : metadata : 2 005 " 

xmlns : tva2="urn : tva : metadata : extended : 2005" 

xmlns :mpeg21="urn : tva :mpeg21 : 2 005 " xmlns :mpeg7="urn : tva :mpeg7 : 2005" 
xmlns : xsi="http : //www . w3 . org/2 001 /XMLSchema-instance" 

xsi : schemaLocation="urn : tva : metadata :extended:2005 tva2_metadata_3-3_vlll . xsd" 
xsi :type="tva2 :ExtendedTVAMainType"> 
<tva2 : CouponTable> 

<tva2 : CouponDescription start="2 004-12-2 ITOO : 00 :00-05:00" end="2 004-12- 
3112 3:59:5 9-05:00" couponId="Channell-2004-12" 
acquisitionMode="immediate"> 
<tva2 : CouponValue> 

<tva2 : ReductionPercentage>20</tva2 :ReductionPercentage> 
</tva2 : CouponValue> 
<tva2 : ContentTarget> 
<tva2 : Genre 

href =" urn : tva : metadata : cs : FormatCS :2005:3.5.7.3" tYpe="main" /> 
</tva2 : ContentTarget> 

<tva2 : CouponURL>http : //www . alt ova . com</tva2 : CouponURL> 
<tva2 : CouponText xml : lang="en-us">Xmas Campaign coupon. 20% off for 
all movies . </tva2 : CouponText> 
</tva2 : CouponDescription> 
</tva2 : CouponTable> 
</TVAMain> 



1 1 Issues per Phase 2 technology 

11.1 Sharing, content and metadata exchange 

There are several issues with sharing content and metadata. There are privacy issues associated with passing personal 
information (TS 102 822-3-1 [2]). There are also security issues with exchanging information with others. 
TS 102 822-5-1 [7] describes the information on rights management for content and TS 102 822-7 [12] for information 
on how to protect metadata over bi-directional links. 



£75/ 



1 24 ETSI TS 1 02 822-2 V1 .3.1 (2006-01 ) 

11.1.1 Content referencing and identification 

The current specifications for content referencing describe how to reference a programme (or group of programmes) 
that can then be eventually resolved to instances of content. In many cases the CRID will refer to content that will be 
available in the future. This model particularly applies to the broadcast case where a broadcaster assigns and manages 
the allocation of CRIDs and their resolution. 

If the user generates content that is to be shared with others, the user may need to provide an identifier so that others can 
refer to that content. The TV-Anytime specifications define mechanisms for resolving CRIDs. The user could use these 
existing mechanisms, that may be provided by a third party. Another alternative is to provide location resolution 
information as part of the metadata. 

There may be a need for identifiers other than the CRID. For example, to identify bit-identical copies of content, for 
rights purposes and to identify content in particular networks. The metadata specification allows Otherldentifiers to 
capture these additional identifiers. 

11.1.2 Sinaring Metadata 

The specifications TS 102 822-3 (all sub-parts) [2] to [5] and TS 102 822-8 [13] cover the transfer of user profile 
information and metadata. If modifications are made to part of the metadata (e.g. creating a more comprehensive 
synopsis), the Phase 2 specifications include support for annotating each metadata snippet with specific authorship. 

11.1.3 Sinaring metadata witin content 

The specifications do not explicitly cover the binding together of metadata and content. 

When content is stored or shared the device will need to store the associated metadata to allow identification later. This 
is needed because, for lots of broadcast content, the metadata will not be permanently available from a broadcaster's 
database. This is especially true where the data is delivered via broadcast as the transmitted data is limited by bandwidth 
constraints. This will probably be also true for online services due to the possibly extremely large volume of data. 

There are issues with storage of metadata - for instance, the metadata may change (e.g. corrections are made to the 
synopsis, or metadata such as segmentation information is added). Another issue is the dynamic nature of grouping 
information - the members of groups will change over time so the stored metadata will not reflect the current status. For 
example, a particular episode in a long running serial will be identified as a member of the series at the time of 
broadcast, but will not be listed several months in the future. So when content is passed around, the metadata may be 
incomplete or different for instances recorded by different users. 

In order to directly associate metadata with content it may be preferable to use a binding format such as AAF or MXF. 
These formats allow the embedding of metadata with the content and in the case of MXF, is able to map the 
TV-Anytime data model to it's own as well as embed XML directly. This will be especially important if the content is 
exported to another medium, e.g. onto a recordable DVD. 

If the content is created from editing or transcoding another source piece of content, the "DerivedFrom" element could 
be used to point to the original content and a new CRID could be used. 



1 1 .2 Remote programming 



One of the key issues with remote programming (TS 102 822-9 [14]) via e-mail is to ensure that only valid e-mails are 
processed. Without some form of security it would be possible for a third party to remotely control the PDR (denial of 
service attack). 

The PDR could be configured with a list of valid sources and then the "From:" field within the e-mail header could 
provide a very basic level of checking, but is clearly not sufficient. It would be better if the e-mail body could be signed 
and/or encrypted in some way. 

The security issue is also raised in the exchange of metadata between friends, even if the impact of "recommend" action 
is more limited than the "record" action. 
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Annex A (informative): 
Example of usage history 



The following example highlights the usage history for the "John Smith" user. During the observation period two 
episodes of the "Fox" series were recorded and subsequently viewed. During the viewing of the "Red Foxes" episode 
the user zoomed in twice. Finally the user previewed the "Blue Foxes" episode. 

<UsageHistory id="usage-historY-001 " allowCollection="true"> 
<mpeg7 :UserIdentif ier protected="true"> 

<mpeg7 :Name xml : lang="en">John Smith</mpeg7 :Name> 
</mpeg7 :UserIdentif ier> 

<mpeg7 rUserActionHistory id="useraction-history-001 " protected="f alse"> 
<mpeg7 :ObservationPeriod> 

<mpeg7 : TimePoint>2001-02-02T18 : 00-08 : 00</mpeg7 :TimePoint> 
<mpeg7 :Duration>PT96H</mpeg7 :Duration> 
</mpeg7 : ObservationPeriod> 
<mpeg7 :ObservationPeriod> 

<mpeg7 : TimePoint>2001-02-02T18 : 00-08 : 00</mpeg7 :TimePoint> 
<mpeg7 :Duration>PT6H</mpeg7 :Duration> 
</mpeg7 : ObservationPeriod> 

<mpeg7 :UserActionList id="ua-list-001" numOf Instances="2" totalDuration="PT2H30M"> 
<mpeg7 :ActionType 
href="urn:tva: metadata :cs:ActionTypeCS: 2004 : 1 .2"> 

<mpeg7 :Name>Record</mpeg7 :Name> 
</mpeg7 :ActionType> 
<mpeg7 : UserAction> 
<mpeg7 :ActionTime> 

<mpeg7 :iyiediaTime> 

<mpeg7 :MediaTimePoint>2001-02-02T19 : 00 : 00</mpeg7 :MediaTimePoint> 
<mpeg7 :MediaDuration>PTlH</mpeg7 :MediaDuration> 
</mpeg7 :MediaTime> 
</mpeg7 : ActionTime> 
<mpeg7 : Programldentif ier organization="TVAF" type="CRID"> 

crid: //broadcaster. com/RedFoxesCrid ForThisEpisode> 
</mpeg7 : Programldentif ier> 
</mpeg7 :UserAction> 
<mpeg7 : UserAction> 
<mpeg7 :ActionTime> 

<mpeg7 :MediaTime> 

<mpeg7 :MediaTimePoint>2001-02-03T19 : 00 : 00</mpeg7 :MediaTimePoint> 
<mpeg7 :MediaDuration>PTlH</mpeg7 :MediaDuration> 
</mpeg7 :MediaTime> 
</mpeg7 :ActionTime> 
<mpeg7 : Programldentif ier organization="TVAF" type="CRID"> 

crid: //broadcaster. com/GreyFoxesCrid ForThisEpisode 
</mpeg7 :ProgramIdentif ier> 
</mpeg7 :UserAction> 
</mpeg7 : UserActionList> 

<mpeg7 :UserActionList id="ua-list-002" numOf Instances="25" totalDuration="PT7H02M"> 
<mpeg7 :ActionType 
href="urn:tva: metadata :cs:ActionTypeCS: 2004 : 1 .2"> 

<mpeg7 :Name>View</mpeg7 :Name> 
</mpeg7 :ActionType> 
<mpeg7 : UserAction> 

<mpeg7 : Programldentif ier organization="TVAF" type="CRID"> 

crid: //broadcaster . com/RedFoxesCrid ForThisEpisode 
</mpeg7 :ProgramIdentif ier> 
</mpeg7 :UserAction> 
<mpeg7 : UserAction> 

<mpeg7 :ActionTime> 

<mpeg7 :MediaTime> 

<mpeg7 :MediaTimePoint>2001-02-04T20 : 30 : 00</mpeg7 :MediaTimePoint> 
<mpeg7 :MediaDuration>PTlM45S</mpeg7 :MediaDuration> 
</mpeg7 :MediaTime> 
</mpeg7 :ActionTime> 
<mpeg7 : Programldentif ier organization="TVAF" type="CRID"> 
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crid: //broadcaster. com/ GreyFoxes Grid ForThisEpisode 
</mpeg7 :ProgramIdentif ier> 
</mpeg7 :UserAction> 
</mpeg7 :UserActionList> 

<mpeg7 :UserActionList id="ual-003" numOf Instances="2" totalDuration="PT10S"> 
<mpeg7 :ActionType 
href="urn:tva: metadata: OS :ActionTYpeGS: 2004 : 1 .2"> 

<mpeg7 : Name>Zoom</mpeg7 :Name> 
</mpeg7 :ActionType> 
<mpeg7 : UserAction> 
<mpeg7 : Programldentif ier organization="TVAF" type="GRID"> 

crid: //broadcaster. com/RedFoxesGrid ForThisEpisode </mpeg7 : Programldentif ier > 
</mpeg7 :UserAction> 
</mpeg7 :UserActionList> 

<mpeg7 : UserActionList id="ual-004" numOf Instances="l"> 
<mpeg7 :ActionType> 

<mpeg7 :Name>Preview</mpeg7 :Name> 
</mpeg7 :ActionTYpe> 
<mpeg7 : UserAction> 

<mpeg7 : Programldentif ier organization="TVAF" type="GRID"> 

crid: //broadcaster . com/BlueFoxesGrid ForThisEpisode 
</mpeg7 :ProgramIdentif ier> 
</mpeg7 :UserAction> 
</mpeg7 :UserActionList> 
</mpeg7 :UserActionHistory> 
</UsageHistory> 
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Annex B (normative): 

Transport environment and requirements 

This annex is a mandatory part of the TV-Anytime set of specifications. 



B.1 Scope 



The current TV-Anytime specifications describe the information structures of content referencing and metadata and how 
these two work together in a system context. There are however a lot of features needed to deliver TV-Anytime services 
that are not specified in the TV-Anytime environment. Examples of these features are the actual carriage of the 
TV-Anytime data, exact start and stop times of programmes, the carriage of the content, the linkage of TV-Anytime 
metadata timelines to actual transmission timelines etc. 

The goal of the transport interface specification is define the requirements that TV-Anytime services need from the lower 
layers. Since there may be many lower layer technologies used in the deployment of TV-Anytime, TV-Anytime relies on 
others to actually implement those requirements. TV-Anytime will define a transport agnostic way to get its data across, 
which can be used in different networks and regions in the world. 

The first transport requirements specification focus on uni -directional access, e.g. broadcast networks or unicast or 
multicast over IP networks. 



B.2 Requirements on the Uni-Directional Delivery System 

The underlying delivery system shall: 

1) Enable the transport of valid TV-Anytime information asynchronously to programmes and potentially split 
across different transport mechanisms. I.e. not all TV-Anytime data needs to be encapsulated in the same 
manner. 

2) Provide a method to locate where and what type of TV-Anytime information is being carried, i.e.: 

a) To acquire content resolution information, the location of the RAR - TS 102 822-4 [6] - is the required 
information from the transport layer. 

b) To acquire metadata, the information required from the transport layer are: 

■ the list of available TVA metadata fragment streams; 

■ the signalling of any modification occurring on them such as the addition of a new TVA metadata 
fragment stream or the removal of an existing one; 

■ the fragment types or categories of TVA fragments carried in each TVA metadata fragment stream 
and information about their respective scope (e.g. list of broadcast channels, specific CRID); 

■ the location of their respective entry points, namely the "TVAInit" message and possibly the 
"TVAMain" fragment if delivered separately; 

■ For the containers of each metadata fragment streams, the transport layer shall: 

signal the Id of each container, its type and its location; 

identify the version of each container - The current version of each container shall be 
signalled, and this shall be incremented whenever the contents of a container change; 

allow monitor at a single point for version changes to a container. Ideally it should be 
possible to monitor just data containers, or if provided, just containers forming a single index; 

allow to download all TVA metadata description containers (preferably in a parallel manner). 
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3) Provide locators (as specified in TS 102 822-4 [6]) for identification and location of content instances. 
Locators are also required to access fragments of TV-Anytime information. 

4) Enable the insertion of certain types of TV-Anytime data (content referencing CRIDs, RMP information and 
metadata) along with the audiovisual content. TV-Anytime will define the syntax and semantics of such data. 

5) Provide a mechanism to map from the linear timeline used by the TV-Anytime segmentation information to 
positions in the actual content e.g. NPT. A linear timeline is used on a captured piece of content for 
segmentation purposes to enable random access to segments of the content. 

6) Provide a signalling mechanism to accurately capture a piece of content referenced by a CRID, even if this 
content is interleaved with other pieces of content. 

7) Enable the repeated transmission of TV-Anytime data. Repetition rates shall be flexible and it shall be possible 
to vary repetition rates for different types of TV-Anytime information. It shall not be necessary to wait for a 
whole repetition period of the whole TV-Anytime dataset to start decoding TV-Anytime data. 

8) Support the selective updating of TV-Anytime information. The underlying delivery system shall not limit the 
TV-Anytime data size and allow for flexible update unit size for different TV-Anytime data types. Updates shall 
not cause data inconsistency at the receiver, even if previous updates have been missed. For efficient operation 
the underlying delivery system should provide an easy means of signalling updates of TV-Anytime 
information. 

9) Accommodate for potential limited processing capability and memory at the receiver. It shall encapsulate 
TV-Anytime data in such a way that graceful recovery from transport errors is possible. The underlying 
delivery system may need to provide "wall clock time" to enable comparison of usage data. 

10) Provide a means for transporting TV-Anytime information that is robust to transmission errors, so that the 
TV-Anytime data is received error free or is signalled to be in error. 
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